Vous n'êtes pas identifié(e).
Pages : 1
Merci à vous pour ces promptes précisions.
Juste un petit clin d'oeil à la documentation sur les varchar(n) :
An attempt to store a longer string into a column of these types will result in an error, unless the excess characters are all spaces, in which case the string will be truncated to the maximum length
Pas si clean que cela
Pourtant il me semble bien que la norme SQL prévoies le troncage. Il s'agit, tout de même, du même type fondamental. Alors pourquoi en ligne de commande, un select ('test'::varchar)::varchar(3); passe correctement en renvoyant 'tes' ? Est-ce à cause du traitement de la fonction que la logique diffère ?
Bonjour,
Venant juste de passer de la 8.4 à la 9.0, je viens de rencontrer un petit soucis. Une fonction en Plpgsql doit retourner un type de données propriétaire. Ce type comporte un varchar(n). Dans la fonction , le retour se fait, après concaténation de chaînes, par un cast varchar. Voici les déclarations :
CREATE TYPE my_type AS (a int2,b varchar(61), c int2);
CREATE OR REPLACE FUNCTION my_fonction(integer, integer, integer,boolean) RETURNS SETOF my_type AS '
.
.
.
for my_record in select ...., (ch1 ||'' ''||ch2)::varchar ....
Et voici le message d'erreur obtenu avec cette nouvelle version :
Returned type character varying does not match expected type character varying(61) in column 2
Si je remplace par (ch1 ||'' ''||ch2)::varchar(61) cela fonctionne. Mais là n'est pas le but car il faudrait vérifier l'ensemble des fonctions et programmes. Je ne comprends pas le pourquoi, surtout que cette erreur n'est présente qu'en 9.0 et que cette syntaxe me semble correcte.
Merci si vous avez une idée sur la question.
Bonjour,
Je suppose que votre réinstallation système s'est faite à partir de l'ancien et non pas à neuf?
Désinstaller PostgreSQL n'implique pas la suppression du compte postgres. Il faut donc que vous le supprimiez manuellement dans les utilisateurs. Attention s'il vous reste un répertoire data, le nouveau compte n'aura pas les autorisations qu'avait le précédent.
Bon courage.
Bonjour,
Je prends le post un peu en retard. D'après ce que j'ai pu constater, il n'y a plus de compte service et de compte super utilisateur postgres. Depuis la 8.4 sous Windows, un seul compte demeure, avec certaines obligations (pas administrateur machine, mot de passe complexe notamment sous AD, certains droits sous la GPO,...). Le mieux quand il s'agit de changer de version majeure, est de désinstaller proprement l'ancienne. Bien que le dossier data ne soit pas touché, au moins un dump avant rassure. A supprimer manuellement aussi l'ancien compte (avant 8.4), celui-ci reste après désinstallation et m'a toujours causé des soucis sinon. Un bon nettoyage, comme n'importe quel programme, et vous repartez sur des bonnes bases. Pensez aussi à conserver votre pg_hba.conf et à reprendre le nouveau postgresql.conf .
Dans mon exemple, vous pouvez remplacer la valeur 0 par n'importe quoi. Mais au-delà de ceci, que ce soit en php ou en sql, il y a un problème de cohérence dans votre base (ou dans ma tête). Comment peut-il y avoir des projets sans responsable? Ou si cela doit se faire (valeur null), ne serait-ce pas une union entre les projets avec et les projets sans?
Bonjour,
Si vous désirez récupérer tous les champs sans qu'une couche logicielle râle, vous pouvez , peut-être, essayer de remplacer la valeur NULL par une autre :
select case when mon_champ is null then 0 else mon_champ end .....
Sinon , pouvez-vous nous communiquer votre requête initiale?
Je n'ai pas essayé les lettres accentuées, mais pour le reste cela fonctionne plutôt bien, y compris les décimaux. Cela dépend peut être de la configuration, aussi.
Bonjour,
et quelque chose comme
SELECT mon_champ FROM ma_table ORDER BY UPPER(mon_champ);
La fonction upper à l'air d'aider au tri en plaçant les champs à null, puis les nombres et enfin les lettres.
Je pencherai plutôt pour ceci, sauf erreur de ma part :
SELECT regexp_matches('SUNNYBROOK & WOMENS HOSP,2075 BAYVIEW, TORONTO, ON M4N 3M5, CANADA', '[A-Z]\\d[A-Z]\\s\\d[A-Z]\\d');
J'en ai maintenant la preuve, le Paradis existe
C'était écrit tellement petit dans la documentation que j'y suis passé à côté (la police de caractère n'est pas des plus lisible). J'ai pas tenté le zéro à cause du réflexe 0=première ligne. Merci à vous.
Bonjour Guillaume,
Je ne m'attendais pas à tant de réactivité Pour ma part, je pense que la configuration par session est parfaite, cela correspond à un besoin à un moment donné. Le ALTER USER me semble plus risqué, mais diablement tentant? Cela fonctionne-t-il dans le cas d'un trigger rebouclant sur lui-même? Y-a-t-il un message d'erreur (capturé par une exception?) avec l'abandon de la transaction en cause?
Je suis bien conscient que l'on ne peut pas inclure tous les paramètres possibles et imaginables, néanmoins ne pas planter bêtement son environnement de développement me semblait intéressant. Dans tous les cas , un grand merci.
Bonjour,
Voulant faire une itération sur un curseur, il m'est venu l'interrogation suivante : Comment revenir proprement au début?
J'utilise la commande Fetch pour me balader et move first à la fin. Oui mais voilà, après le move, la commande fetch passe au next, sautant le premier enregistrement. Illustration avec un exemple:
loop
fetch from my_cursor into my_record;
exit when my_record is null;
.
.
.
end loop;
move first from my_cursor;
move backward from my_cursor; --force le curseur au BOF
Je dois mal m'y prendre, il y a sûrement une façon de coder d'une meilleure façon. Merci de bien vouloir m'éclairer ;)
Whoua! Merci Guillaume pour cette réponse fulgurante. Je me doutais bien que non, mais avec l'idée que cela pourrait intéresser. Rien de bien méchant effectivement, mais quand on doit recommencer de configurer l' environnement précédent avec une dizaine de fenêtres
Bonjour,
Une petite question plutôt destinée à Guillaume. Y-a-t-il un timeout lors d'une requête exécutée via PgAdmin (1.8.4 Windows)? Je n'ai rien trouvé dans les préférences et rien non plus côté base dans le postgresql.conf. A l'origine de cette interrogation, j'ai lancé une requête d'alimentation de table et machinalement rafraîchis les données. Malheureusement, un produit cartésien a fait que la requête bouclait à l'infini. Trop tard, les fenêtres de pgAdmin se sont figées et plus moyen d'en sortir. La seule solution a été de détruire le process, laissant bloquée du même coup la table avec impossibilité d'y accéder ou de la détruire ultérieurement.
J'ai pu tout de même annuler la transaction et retrouver mon petit monde
Bonjour,
Je méconnais Vista, mais pour avoir rencontré pas mal de soucis d'installation sur du 2003 j'ai une petite idée. Avez-vous accès à la console secpol.msc ? Si oui, pouvez-vous vérifier dans les" stratégies locales" et" attributions des droits utilisateurs" si le compte postgres possède le droit "ouvrir une session en tant que service" ? Cela peut-être une piste, car les pannes sous Windows...
Normalement, la requête suivante devrait fonctionner :
Insert into matable(id,name,obs) Values(nextval('tarifaire_indtarif_seq'),'test3','test3');
Evidemment, j'ai codé en réalité avec un case, mais je voulais simplifier la syntaxe de ma requête déjà bien lourde. Dans mon exemple, je voulais détourner la fonction pour qu'elle retourne la chaîne ou null. J'ai bien conscience qu'insérer un null dans une chaîne est absurde. Mais j'avoue tout de même être surpris.
Merci à vous, je suis rassuré sur le fait qu'il n'y a pas une réponse si simple que cela.
Bonsoir,
Avez-vous essayé en précisant nextval(''my_id_seq") pour le champ id? Votre séquence est-elle à la bonne valeur (comme Guillaume le demandait)?
Bonjour,
Fraîchement inscrit et déjà une question
Je ne sais pas si le problème a déjà été évoqué (rien trouvé par la recherche) au sujet de la fonction text "replace". Je voulais un traitement particulier et je n'ai pas été déçu! Voici un exemple :
select replace('ABCD','E',null)
Je m'attendais à la chaîne ABCD mais en fait, on obtient null en retour quelque soit le test. Pourquoi? On peut bien affecter null à un type text pourtant.
Si quelqu'un sait où je commets une erreur de raisonnement, merci à lui de me remettre sur le droit chemin
Pages : 1