Vous n'êtes pas identifié(e).
Bonjour,
en complément, le comportement que vous constatez provient du fait que le schéma public est, par défaut, positionné avec les droits CREATE ET USAGE pour tous les utilisateurs.
Si ce réglage par défaut ne convient pas il est bien sûr possible de retirer ces droits par un REVOKE CREATE, USAGE ON SCHEMA public FROM PUBLIC ou, plus raisonnablement pour les seuls droits de création, par un REVOKE CREATE ON SCHEMA public FROM PUBLIC.
Bonjour,
si la liste de choix est relativement constante vous pouvez utiliser les types énumérés.
Sinon il y a toujours la possibilité de créer une table stockant les valeurs possibles et d'y faire référence dans la table utilisatrice avec une contrainte de clef étrangère.
Bonjour,
@Papychampi votre requête n'est pas claire.
Si je pars sur l'hypothèse que ce que vous cherchez à faire dans votre procédure stockée est de récupérer le numéro de série suivant d'une colonne de type séquence
vous pouvez pour une table ressemblant à ca:
CREATE TABLE test(
num_serie SERIAL,
data1 integer...
);faire la requête suivante dans votre procèdure stockée:
...
INSERT INTO test(data1) VALUES(9999) RETURNING num_serie INTO ma_variable_de_ma_procedure_stockee;
...qui placera dans ma_variable_de_ma_procedure_stockee le numéro de série suivant.
Le principe est, si c'est possible,de laisser faire la base pour attribuer le numéro de série.
Pourquoi "si c'est possible" ? Parce que les séquences PostgreSQL peuvent avoir des "trous" car même si la transaction dans laquelle se situe l'appel à nextval est annulée (rollback)
le numéro de série est considéré quand même comme attribué (il ne sera pas réutilisé).
Si votre application ne tolère pas ce genre de saut il faut trouver une autre solution qui risque d'être beaucoup beaucoup moins simple avec plein d'inconvénients... mais dont le principe
va être de de bloquer certrains accès concurrent à la table pendant qu'une transaction attribue un nouveau numéro. Comme ca je dirais que la transaction enveloppante (celle dans laquelle s'exécute
la procédure stockée) doit être positionnée sur SERIALIZABLE et que l'application doit être prête à gérer les annulations des transactions en cours.
SELECT family AS _family FROM product_types WHERE ptypeid = _ptypeid[j]; -- CETTE LIGNE LA BUGL'errreur est claire: il manque une destination, c'est à dire une variable dans laquelle mettre le résultat de la requête:
SELECT family AS _family FROM product_types WHERE ptypeid = _ptypeid[j] INTO myvariable;Merci.
Donc la requête:
SELECT ptypeid AS _ptypeidtab FROM product_types WHERE family = _family; // retourne un tableaune retourne pas un tableau contrairement au commentaire indiqué mais un ensemble de lignes de type entier (integer).
Et la requête qui doit extraire les lignes de la table products ne serait plus:
SELECT max(x'right( sn, 4)'::integer) AS _dddd FROM products WHERE ptypeid = _ptypeidtab; // Doit faire une requête avec tout le contenu du tableaumais plutôt:
SELECT max(x'right( sn, 4)'::integer) AS _dddd FROM products WHERE ptypeid IN (SELECT ptypeid AS _ptypeidtab FROM product_types WHERE family = _family) ; Quoi que le 'x' dans max(x'right... doit être plutôt perturbant ;-)
Voir même plus simple en fonction de la définition de la table products.
Sinon sur le principe, et dans la mesure où ptypeid est automatiquement alimenté par la clause "DEFAULT nextval..." pourquoi voulez vous calculer vous même cet entier alors que la base va le créer automatiquement ? Mais bon peut être n'ai je pas tout compris ou il y a des choses qui m'échappent...
Merci pour ces précisions qui permettent de mieux comprendre ce que vous voulez faire mais il manque encore un élément essentiel à savoir la définition exacte de la table product_types.
Est-il possible d'avoir la requête SQL CREATE TABLE concernant cette fameuse table product_types au au minimum les types de chaque colonne ? Ou le résultat sous psql de \d product_types ?
Bonjour,
est-il possible d'avoir la définition de la table product_types ou au minimum de la colonne ptypeid ?
Que fait exactement:
max(x'right( sn, 4)'::integer)?
Pouvez vous expliquer ce que vous cherchez à faire d'un point de vue logique ? Dans le style "Je voudrais extraire le maximum des 4 1ers caractères convertis en nombre de...".
Tout cela permettrait de comprendre le but de l'opération et sur quelle structure de données s'appuie les requêtes.
@GhostSpirit vous ne pouvez pas en dual boot avoir un répertoire de données (cluster) qui a été initialisé sous Debian puis rebooter sous Windows et lancer le serveur PostgreSQL sur le même répertoire de données. Et inversement (initialisation sous Windows et servi sous Debian). Car, comme expliqué précédemment le format du cluster (les fichiers physiques qui constituent le cluster) n'est pas universel pour toutes les plateformes et architectures existantes.
D'où la notion de serveur tiers évoqué qui serait un 3ème ordinateur (physique ou virtuel) qui ferait office de serveur PostgreSQL d'un cluster de données initialisé et servi par cette 3ème machine. Les 2 1ères (Debian et Windows en dual boot sur le même ordi physique) accèderaient ce serveur avec des binaires qui leur sont propres (un jeu de binaires Windows pour Windows et un jeu de binaire Debian pour Debian): psql, pgadmin... n'importe quels clients qui "parlent" tous le même protocole et qui peuvent donc s'adresser au serveur PostgreSQL hébergé sur la 3ème machine (n'importe quel serveur hébergé sur n'importe quelle machine).
Est ce que c'est plus clair maintenant sur ce qui est faisable et ce qui ne l'est pas ?
Je pense que Julien faisait allusion au fait qu'une instance physique (le répertoire des données et tous les fichiers inclus) ne peut être servi que par un serveur de même plateforme et architecture que le binaire qui a initialisé la base de données (initdb -D xxxx).
Mais bien entendu le serveur peut répondre à n'importe quel type de client indépendamment de la plateforme ou architecture pour laquelle il a été compilé.
Bref, le binaire du serveur doit être compatible avec le binaire qui a créé le cluster/l'instance. Par contre, les accès à cette base n'ont pas cette contrainte car ils n'accèdent pas directement le cluster mais interagissent avec le serveur qui lui lis les données du cluster.
Bonjour,
nul besoin d'installer le serveur, pg_dump fait partie des programmes clients.
Par exemple, sous Debian il suffit d'installer le paquet postgresql-client-common. Il doit en aller de même sous toutes les distributions (je suppose que le serveur web est hébergé sous linux).
Bonjour,
oui j'imagine qu'il faut plutôt le formuler comme cela (à tester):
select query_to_xml(
$$WITH myselect AS
(select client_id
from client
where client_id = '1649'
)
SELECT * from myselect$$ , TRUE, TRUE, ''
)
;Le texte de la requête, argument de la fonction query_to_xml, doit être complet. La fonction ne connaît que ce qu'on lui passe.
Du coup, c'est quoi l'intérêt dans la nouvelle version d'utiliser la syntaxe GET STACK etc?
L'intérêt c'est de pouvoir récupérer, si besoin, plus d'information que ce qui est fourni avec les seules variables SQLSTATE et SQLERRM.
Voir ce tableau dans la doc pour la liste des infos disponibles.
Bonjour,
il me semble que vous confondez plusieurs choses: les triggers au sens SQL sont des actions que le moteur de base de données lancent lorque certains événements surviennent dans une table appartenant à une de ses bases de données: insertion de lignes, mises à jour, suppression. Voir la doc sur ce sujet.
Ce que vous cherchez à faire (enfin si j'ai bien compris) est une action qui est la conséquence d'un événement système: l'ajout d'un fichier à un répertoire. PostgreSQL ne suit pas ces événements et ne peut donc pas y réagir par un trigger.
On sort un peu (beaucoup ;-)) du cadre de ce forum mais cherchez du côté de inotify. Vous pourrez probablement attacher un script qui met à jour la base de données dans le sens recherché.
En complément de la réponse de Marc qui semble judicieuse, l'erreur de syntaxe rapportée est normale puisque la documentation précise:
Le résultat d'une commande SQL ne ramenant qu'une seule ligne (mais avec une ou plusieurs colonnes) peut être affecté à une variable de type record, row ou à une liste de variables scalaires
scalaires... les variables de type tableau sont donc exclues.
Je suis un peu étonné que cela puisse fonctionner car, sauf erreur, l'instruction:
insert into mytable(value)
select "first insert"
union select "second insert"
union select "third insert"
returning id into myReturnTable;retourne plus d'une ligne (3 en l'occurence). Ce qui devrait lever une erreur à l'exécution, non ?
Quel est le type de myReturnTable ?
Si vous avez accès au serveur vous pouvez voir et éventuellement modifier les paramètres tcp_keepalives_*.
Sinon vous pouvez aussi ajouter des options de connexion au niveau du client (keepalives*) mais avec pgAdmin je crois comprendre qu'il fallait passer par un fichier de connexion de services.
Voir cette échange (en anglais).
Est ce que la déconnexion automatique est toujours présente avec un autre client (psql par exemple) ?
C'est étonnant... Je ne connais pas pgAdmin mais je serais étonné qu'il "s'amuse" à vider le fichier .pgpass au lieu d'exploiter son contenu.
D'autant plus qu'il utilise a priroi libq qui est la librairie qui exploite .pgpass.
...
Je viens de regarder rapidement la doc de pgAdmin: est ce que vous n'auriez pas décoché la case "Store password" lorsque vous avez paramétré votre connexion ?
Dans ce cas ca semble logique que pgAdmin remette à zéro l'entrée correspondante dans le fichier .pgpass. Cochez cette case pour voir.
Bonjour,
pour le 1er problème je ne sais pas je n'utilise pas pgAdmin.
Pour le second probablement que les types des données passés à la fonction sont différents de ceux attendus.
Regardez à nouveau l'appel qui est fait et éventuellement "castez" vos données pour les faire correspondre à la signature de la fonction.
C'est d'ailleurs le conseil (HINT) qui vous est donné par le serveur.
Bonjour,
probablement que l'utilisateur sous lequel vous lancez pgAdmin n'est pas le même que celui qui lance les scripts qui fonctionnent.
Après avoir essuyé un échec avec pgAdmin est ce que les scripts évoqués plus haut continuent à fonctionner ?
Si oui c'est que les scripts et pgAdmin n'utilisent pas le même fichier .pgpass et que les utilisateurs sont donc différents.
Bonjour,
vous n'avez pas de sauvegarde ?
Bonsoir,
Pouvez vous indiquer la requête en erreur ainsi que la définition de la ou des tables objets de la requête ?