Re: [pgsql-fr-generale] Re: [pgsql-fr-generale] Re: [pgsql-fr-generale] Migration de base de donnée MSSQL -> PGSQL

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Toffe wrote:

| temsa a écrit : (...)
|
|> | | Si je comprends bien, vous attendez de PG qu'il fasse fi des
|> | doubles quotes?...
|>
|> non, je veux qu'il fasse ni plus ni moins que MSSQL dans ce
|> domaine: quand il n'y a pas de table toto mais une TOTO, qu'il se
|> dise que ça pourrait bien être la table qu'il faut!
|>
| Excusez moi d'insister mais la doc indique très clairement que
| c'est le fonctionnement NORMAL ce que vous décrivez ici. Vous
| pouvez très bien appeller une table Toto et l'appeller avec TOTO ou
| tOtO si ça vous chante... Le fait de mettre des double quotes fait
| que postgresql rends sensible à la case les noms mis entre ces
| double quotes; dans notre cas il faudra appeller Toto si l'on veux
| éviter les erreurs.
|
| (...)
|
|> | Par exemple, elle serait liée à une clé dans le fichier |
|> postgresql.conf, et aurait une syntaxe de ce type: | |
|> ignore_double_quotes = true
|>
|> ouais tout a fait, plues exactement comme ça: ignore_case=true
|
|
| Vous allez rire... mais je suppose que vous aurez compris en me
| lisant dans le paragraphe ci dessus; ce que vous voudriez avoir
| dans la conf existe DÉJÀ.

Bon je veux bien le croire, mais il me semble que j'avais tout de même
eut des problèmes, en effet, ce doit aussi venir des tables entre
guillement qui ne doivent pas être case sensitive, je suppose.
J'enverrais un mail pour leur demander de retenter une migration
directe avec les tables an majuscule, voir ce que ça donne.

Mais ça veut dire que MSSQL n'est pas sensible à la casse lorsque
c'est entre guillemet, ca me parait bizarre(mais possible!), et dansce
cas je pense que le hack ne doit pas être trop dure.

Je crois que je me suis bien embêté pr pas grand chose si c'est vrai.
Ca peut aussi venir du fait que j'ai découvert plus tard que ma base
étant en local UTF-8, elle ne supportait apparament pas certains
caractères, ce qui a fait rater un certain nombre d'importation de
données, ce dont je ne me suis pas rendu compte de suite.

D'ailleurs j'ai trouvé dommage que dans pgadmin3 on puisse voir qu'une
table ou une base de donnée soit dans une locale particulière, et
qu'il n'y ai rien, à ma connaissance, pour en changer (c'est une
combobox grisée de mémoire). Surtout que d'après ce que j'ai lu, ça
pose des problèmes avec LIKE, qui deviens alors moin performant. Pour
remettre la base en SQLASCII, j'ai suivit les conseils de
http://pbpgsql.spiderbark.com/index.php?module=announce&ANN_user_op=view&ANN_id=7

en faisant un dumpall puis en refaisant un initdb, ce qui a résolu mes
problèmes avec les mots du type "RHÔNE" qui refusaient de d'insérer
(apparament les majuscules accentuées ne passent pas en UNICODE)

|
| Je pense sincèrement qu'une lecture de ce passage de la doc parlant
| de la syntaxe vous donnerait foison d'indices.

J'ai déjà lu la doc, sans doute l'avais-je mal comprise.

|
| Cordialement.
|
En tout cas merci,

Cordialement.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBTvPUi2j5R/FksdIRAlkBAJ4gMtsB3Z1WDDrFhE0ST/uQW3jLkACeKMRp
slkxyvtHcwIqzPxwxHN8XRo=
=LKsA
-----END PGP SIGNATURE-----