Champ TEXT sur plusieurs lignes

Bonjour,

j'ai parcouru la doc de PostgreSQL et la FAQ de developez.com sans trouver une réponse à ma question :

Comment faire du INSERT INTO sur un champ de type TEXT ? Pour du VARCHAR ça donne : 'du texte', par contre j'aimerai pouvoir faire avec un TEXT :

Code:

---

1 2 3 4 5 6

INSERT INTO matable VALUES ("Un peu de texte ici.     Sur plusieurs lignes etc... ...");

---

Les double guillemets ne sont pas valdes pour tu texte, y a t-il un moyen de contourner cette limitation ?

EDIT : La souttion est-elle ici ?

http://www.postgresql.org/docs/9.1/s...x-lexical.html

Point 4.1.1.2.

Avec des simples quotes :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

create table test_text (c1 integer, c2 varchar(10), c3 text);   insert into test_text values (1, 'ABC', 'Un peu de texte ici.     Sur plusieurs lignes etc...');     select c1, c2, c3 from test_text;   | c1 | c2 | c3 | |----|-----|------------------------------------------------------| | 1 | ABC | Un peu de texte ici.     Sur plusieurs lignes etc... |

---

Effectivement, le tout fonctionne correctement, les double quotes sont considérés comme des guillemets normaux, par contre, je n'ai pas réussi à y insérer des simple quotes dans le champ, Postgre n'a pas l'air d'apprécier l'échappement de caractère : \'.

La source de la documentation est celle que j'ai posté au départ.

Citation :

Citation:

---

Any other character following a backslash is taken literally. Thus, to include a backslash character, write two backslashes (\\). Also, a single quote can be included in an escape string by writing \', in addition to the normal way of ''.

---

Essayez en doublant la quote

Salut
Essaye le double dollar $$

Code:

---

1 2 3 4 5

insert into test_text values (1, 'ABC', $$Un peu de texte ici.     Sur plusieurs lignes etc...$$);

---

@+

Citation:

---

Envoyé par escartefigue

Essayez en doublant la quote

---

J'ai essayé de 2 manières :

Cette partie ne fonctionne pas :

Code:

---

1 2	INSERT INTO maTable VALUES('du texte avec des simple quotes ici : \''');

---

Celle ci fonctionne :

Code:

---

1 2	INSERT INTO maTable VALUES('du texte avec des simple quotes ici : '');

---

Ton indication est donc correcte, pas très cohérent par rapport à ce que mentionne la documentation mais c'est peut-être une mauvaise interprétation de ma part. Merci !

ça fait partie du langage SQL de base depuis sa création !!!
Votre syntaxe est fausse car vous ne terminez pas la chaine...

Code:

---

1 2	INSERT INTO maTable VALUES('du texte avec des simple quotes ici : ''');

---

Code:

---

1 2 3

INSERT INTO maTable VALUES('du texte avec des simple quotes ici : ''');

---

Code:

---

1 2	INSERT INTO maTable VALUES('du texte avec des simple quotes ici : ajourd''hui le fait d''apprendre SQL rebute quelqu''un');

---

Apprenez le langage SQL. Mon site comme mon bouquin, peuvent vous y aider !

A +

Citation:

---

Envoyé par SQLpro

ça fait partie du langage SQL de base depuis sa création !!!
Votre syntaxe est fausse car vous ne terminez pas la chaine...

Apprenez le langage SQL. Mon site comme mon bouquin, peuvent vous y aider !

A +

---

SQL syntex 4ème édition ?

J'ai rien contre acheter un livre, après forcément venant de l'auteur, l'avis est forcément partial, le problème est ailleurs, comme avait dit fsmrel sur un MLD d'un de mes projets persos (cf. ici) :

Citation:

---

Mais, vérité en deçà du territoire d’un SGBD, erreur au-delà... Si l’on passe à SQL Server, on se fait jeter si on code CASCADE dans le cas de l’auto-référence ! Encore un diktat, aussi contestable, et aussi peu justifié que dans le cas de DB2 !

---

C'est bien le coeur du problème :
- Projet perso : MySQL (choix par défaut car inclut avec WAMP) mais a au moins le mérite de pouvoir utiliser MySQL Workbench pour générer automatiquement des tables
- Au boulot : PostgreSQL : bien plus respectueux des standards, par contre les outils annexes pour créer un MLD me parait préhistorique (c'est un avis perso hein) pour un SGBD vieux de 20 ans, quand au debug, je n'en parle même pas en ligne de commande. A quand un Management Studio pour Postgre ? 2030 ?
- Ma préférence et votre livre : orienté SQL Server.

Difficile de choisir.

Là encore je donne mon avis, le problème de trop nombreux projets open source est de fournir des outils semi finis assez peu adaptés à des clients finaux, exemples :
- PG pour les arguments que j'ai cité précédemment,
- Unix, Linux : à l'exception d'OS X, difficile de se passer de la ligne de commande, la distrib Debian avec XFCE que j'ai, n'a pas de d'option de recherche tel que sous Windows : ligne de commande quasi obligatoire. En termes d'UX, Windows 95 faisait mieux et c'est la vérité. Bon c'est discutable selon la distrib utilisée.
- Le VB OpenOffice : mon dieu quelle horreur, Office 97 avait la décence de fournir de l'intellisense, en 96.

Code:

---

1 2	INSERT INTO maTable VALUES('du texte avec des simple quotes ici : ajourd''hui le fait d''apprendre SQL rebute quelqu''un');

---

Oh pas le moins du monde. C'est les ORM qui sont une abérration, Je n'ai aucun problème avec du SQL, bien au contraire.

Citation:

---

Envoyé par Aizen64

je n'ai pas réussi à y insérer des simple quotes dans le champ, Postgre n'a pas l'air d'apprécier l'échappement de caractère : \'.

La source de la documentation est celle que j'ai posté au départ.

Citation :
Any other character following a backslash is taken literally. Thus, to include a backslash character, write two backslashes (\\). Also, a single quote can be included in an escape string by writing \', in addition to the normal way of ''.

---

Il faut remettre cette citation dans son contexte. Le titre du paragraphe est String Constants with C-style Escapes et il commence par:

Citation:

---

PostgreSQL also accepts "escape" string constants, which are an extension to the SQL standard. An escape string constant is specified by writing the letter E (upper or lower case) just before the opening single quote, e.g., E'foo'

---

Quand on n'utilise pas ce formalisme de chaîne préfixé par E, le backslash est un caractère normal et les règles mentionnées dans ce paragraphe ne s'appliquent pas.

Exact. C'est un peu la problématique de n'avoir lu la doc que partiellement. :weird: