Re: Mig

> Bonjour,

Bonjour!

> j'ai réussi cette migration sans encombre, mais je n'ai pas réussi a
> trouver une option permettant de faire en sorte de faire fonctionner
> correctement une requete sql du type "select toto from bidule" et
> qu'en fait la table s'appelle "BIDULE" et le champ "TOTO" .

Oui, c'est tout bête!

Vous devez juste avoir des requêtes à la M$ SQL avec les champs entre doubles
quotes: pour PostgreSQL cela signifie que vous lui interdisez de chercher une
table qui s'appellerait Toto ou toto..., que vous le forcez à requêter dans la
table TOTO en majuscules.

Pour que tout cela marche, il vous suffit simplement de retirer les " (doubles
quotes) de vos sources SQL...

Pour se faire, en perl, -par exemple:

perl -i -pe 's/"//g' *.sql

retirera toutes les doubles quotes de vos sources SQL .. (attention, j'ai bien
dit TOUTES! :)...)

Au final, votre SQL sera bien plus lisible, sans toutes ces doubles quotes, non?

Bonne soirée,

--
Jean-Paul ARGUDO

Site perso : http://www.argudo.org
PostgreSQL : http://www.postgresqlfr.org
l'APRIL : http://www.april.org

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

Bonjour,
j'ai réussi cette migration sans encombre, mais je n'ai pas réussi a
trouver une option permettant de faire en sorte de faire fonctionner
correctement une requete sql du type "select toto from bidule" et
qu'en fait la table s'appelle "BIDULE" et le champ "TOTO" .

Je sais que ce n'est pas un comportement "normal", néanmoins je me
demandais si ce serait possible, le cas échéant ça pourrait être très
bien pour migrer les applis qui utilise cette fonctionnalité de MSSQL...

J'ai peut être mal cherché, je ne sais pas, mais je ne l'ai pas vu
dans la configuration de postgres et je n'ai rien trouvé là dessus...
est-ce possible à faire?

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

iD8DBQFBTcGoi2j5R/FksdIRAsKHAKCKm+W6XDVfQZcA1Y2pzyijlp3R5gCeJ52Y
jORAJLUk8rXrkzpasUVC/us=
=x8rv
-----END PGP SIGNATURE-----

On Sun, Sep 19, 2004 at 07:21:20PM +0200, Jean-Paul ARGUDO wrote:
> > Bonjour,
>
> Bonjour!

Bonsoir à vous deux.

> > j'ai réussi cette migration sans encombre, mais je n'ai pas réussi a
> > trouver une option permettant de faire en sorte de faire fonctionner
> > correctement une requete sql du type "select toto from bidule" et
> > qu'en fait la table s'appelle "BIDULE" et le champ "TOTO" .
>
> Oui, c'est tout bête!
>
> Vous devez juste avoir des requêtes à la M$ SQL avec les champs entre doubles
> quotes: pour PostgreSQL cela signifie que vous lui interdisez de chercher une
> table qui s'appellerait Toto ou toto..., que vous le forcez à requêter dans la
> table TOTO en majuscules.

en effet, après l'avor testé PG réponds ce genre de choses:
Intranet=# SELECT "NOM" from "HOSTING" limit 1;
ERROR: relation "HOSTING" does not exist

et idem si il n'y a que le nom de la colonne entre doubles quotes.

> Pour que tout cela marche, il vous suffit simplement de retirer les " (doubles
> quotes) de vos sources SQL...
>
> Pour se faire, en perl, -par exemple:
>
> perl -i -pe 's/"//g' *.sql
>
> retirera toutes les doubles quotes de vos sources SQL .. (attention, j'ai bien
> dit TOUTES! :)...)
>
> Au final, votre SQL sera bien plus lisible, sans toutes ces doubles quotes, non?

Il est fait mention de la sensibilitée à la casse dans cette page de la
doc de PG: http://www.postgresql.org/docs/7.4/interactive/sql-syntax.html à
la section nommée «4.1.1. Identifiers and Key Words».

Bonne continuation.

--
Toffe
UIN #39872819
http://www.nah-ko.org/ - http://www.zrx21.com/

Il faut mettre le préservatif à l'index !
Monseigneur De Courtrai

temsa wrote:
> | Pour que tout cela marche, il vous suffit simplement de retirer les
> | " (doubles quotes) de vos sources SQL...
>
> c'est exactement ce que j'ai fait, a ceci près que j'utilise un
> lnagage (à la con, du moins pour ça) qui ne stocke pas ses sources en
> clair, mais à moitié en bianire: powerbuilder...
>
> |
> | Pour se faire, en perl, -par exemple:
> |
> | perl -i -pe 's/"//g' *.sql
>
> J'ai même utilisé plus compliqué afin de ne retirer à peu près que
> les appels au champs et aux tables...
>
> perl -pi.bak -e 's/"([[:alnum:]_]+)"/$1/g'
>
> mais ceci je l'ai fait dans un export de ma base! parceque j'ai tenté
> de garder ma base en majuscule, ça ne suffit pas, il faut poutr
> pouvoir utiliser TOTO au lieu de "TOTO" dans une requete, que toto
> soit en minuscules dans la base
>
> | retirera toutes les doubles quotes de vos sources SQL ..
> | (attention, j'ai bien dit TOUTES! :)...)
> |
> | Au final, votre SQL sera bien plus lisible, sans toutes ces doubles
> | quotes, non?
>
> ça je suis plutôt d'accord, mais là n'est pas ma question.
> il m'a fallu plus d'une semaine pour passer a peu près 60% de l'appli
> pour postgres. Pendant ce temps la, les développeur ont avancés sur
> pas mal de fichiers, et je ne me vois pas utiliser diff avec des
> fichiers binaires

Plusieurs remarques:

* laissez la liste PostgreSQL Fr en copie! Le débat interresse surement
d'autres personnes;

* je n'avais fait que deviner votre problème, vous auriez pu d'emblée
nous expliquer tout cela :)

* je ne comprends pas bien le planing de votre intervention? Si je
comprends bien, c'est une migration et en même temps ça code d'un autre
côté? Ce n'est pas trop dans les règles de l'art. En théorie, on arrête
tout dév, on migre, puis on continue à developper. Ou alors, vous le
faites sur une branche stable de votre soft (qui n'est pas censée
évoluer, donc)??

* faites passer le mot à vos développeur et votre probleme se résoud
tout seul non? « Pas de doubles quotes dans le SQL, merci les gars »;

> C'est pour ça que je cherche une solution plus simple, consistant a
> configurer la base pour que ça fonctionne directement. C'est plus
> simple tout de même,car le portage est vraiment long, alors qu'il
> pourrait prendre qualques heures au plus avec cette simple fonction!

Si je comprends bien, vous attendez de PG qu'il fasse fi des doubles
quotes?...

Sincèrement je ne vois qu'une solution: hacker PG, trouver le bout de
code qui traite les doubles-quotes dans la requete SQL, et simplement la
by-passer.

Cela nécessite qques connaissances en C, et que vous sachiez compiler PG.

Le *gros* hic, c'est que vous devrez maintenir votre vérue par rapport
aux évolutions de PostgreSQL.

Alors, au final, je vous conseille de rédiger un e.mail explicatif de
votre problème, en anglais, sur la liste des hackers de PostgreSQL, en
leur demandant de bien vouloir implémenter votre fonctionalité dans PG.

Par exemple, elle serait liée à une clé dans le fichier postgresql.conf,
et aurait une syntaxe de ce type:

ignore_double_quotes = true

Je pense que cela solutionnerait votre problème, et pourrait intéresser
toutes les personnes qui migrent depuis M$ SQL.

Au plaisir de vous lire,

Cordialement

PS: je jette un coup d'oeuil dans les sources, des fois que ce soit un
truc facile à faire, je vous envoie le patch :-)

--
Jean-Paul Argudo
www.Argudo.org
www.PostgreSQLFr.org

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À.

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

Cordialement.

--
Toffe
UIN #39872819
http://www.nah-ko.org/ - http://www.zrx21.com/

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

Jean-Paul ARGUDO wrote:

| temsa wrote:
|
|> | Pour que tout cela marche, il vous suffit simplement de retirer
|> les | " (doubles quotes) de vos sources SQL...
|>
|> c'est exactement ce que j'ai fait, a ceci près que j'utilise un
|> lnagage (à la con, du moins pour ça) qui ne stocke pas ses
|> sources en clair, mais à moitié en bianire: powerbuilder...
|>
|> | | Pour se faire, en perl, -par exemple: | | perl -i -pe
|> 's/"//g' *.sql
|>
|> J'ai même utilisé plus compliqué afin de ne retirer à peu près
|> que les appels au champs et aux tables...
|>
|> perl -pi.bak -e 's/"([[:alnum:]_]+)"/$1/g'
|>
|> mais ceci je l'ai fait dans un export de ma base! parceque j'ai
|> tenté de garder ma base en majuscule, ça ne suffit pas, il faut
|> poutr pouvoir utiliser TOTO au lieu de "TOTO" dans une requete,
|> que toto soit en minuscules dans la base
|>
|> | retirera toutes les doubles quotes de vos sources SQL .. |
|> (attention, j'ai bien dit TOUTES! :)...) | | Au final, votre SQL
|> sera bien plus lisible, sans toutes ces doubles | quotes, non?
|>
|> ça je suis plutôt d'accord, mais là n'est pas ma question. il m'a
|> fallu plus d'une semaine pour passer a peu près 60% de l'appli
|> pour postgres. Pendant ce temps la, les développeur ont avancés
|> sur pas mal de fichiers, et je ne me vois pas utiliser diff avec
|> des fichiers binaires
|
|
| Plusieurs remarques:
|
| * laissez la liste PostgreSQL Fr en copie! Le débat interresse
| surement d'autres personnes;

oups, j'avais pas vu!

|
| * je n'avais fait que deviner votre problème, vous auriez pu
| d'emblée nous expliquer tout cela :)

oui, mais je voulais une reponse simple a une question simple. la
reponse est, si je ne m'abuse, que ce n'est pas possible

|
| * je ne comprends pas bien le planing de votre intervention? Si je
| comprends bien, c'est une migration et en même temps ça code d'un
| autre côté? Ce n'est pas trop dans les règles de l'art. En théorie,
| on arrête tout dév, on migre, puis on continue à developper. Ou
| alors, vous le faites sur une branche stable de votre soft (qui
| n'est pas censée évoluer, donc)??
|
A vrai dire, si je dois aller dans le detail, je vais a peu pres tout
vous dire.

Je suis rentré en stage dans une société, et l'un de mes objectifs
etait d'etudier voir de faire une moulinette pour migrer la grosse
appli de la société vers une base disponible sous Linux.

Ils n'ont aucun outil de gestion de version, mais en fait, c'est aussi
parcequ'il n'y a plus que 2 developpeurs (avant la boite faisait
environs 20 personnes, voir plus) . La boite a manquée couler parceque
l'ancien patron n'etait pas très recommandable, il a fait beaucoup de
magouilles, et s'est faché avec beaucoup de clients. Le nouveau patron
régularise tout et m'a l'air bien parti pour remonter la boite
correctement.

De plus, cette boite, c'est le bordel intégral :)

En gros, il y a une version par client (je vous dis pas la merde pour
corriger un bug... il faut le faire 12 fois!), je trouve ça
particulièrement ingérable, et je leur ai qd même parlé de
cvs/arch/subversion/bitkeeper bien que je ne sois pas expert, je pense
que ça pourrait les aider, même si je ne sais pas si c'est capable de
gérer des fichiers à moitier binaire (je pense, mais bon j'en sais
rien, jamais testé).

J'ai bossé sur une version considéré comme stable, et j'ai demandé au
devs de ne plus mettre de guillemet, ce qu'ils ont fait et qu'il
continuent à faire.

Leur base de données est très rustre, il n'y a aucune procédure
stockée (c'est bien pour le portage, mais pas top du tout pour la
lisibilité des programmes) mais j'ai vu avec eux comment en faire et
ils vont peut être s'y mettre (le SQL et les BDD, ils ont appris sur
le tas sans formation...). Personellement, les proc stock je les ai
découvert avec postgres, même si mon frère qui est un dieu de la base
de donnée (son job en gros c'est optimiser les bases de données des
clients) et m'en avais un peu parlé, je ne l'avais pas vu en cours, et
je n'avais jamais eut a en manier pour de simple sites web.

La principale raison pour laquelle leur BDD n'a pas de proc stock,
c'est qu'elle est assez récemment migrée de AS/400 vers MSSQL, et que
ça n'a pas été fait d'une manière terrible si j'ai bien compris. D'où
des noms de tables et de champs en majuscule et limité a 11
caractères, avec une convention de nommage obscure disparue avec les
développeurs qui ne font plus partis de la société.

De plus, il n'y a aucun schéma (MCD par exemple) de la BDD. Alors bon
comme vous le voyez, les "Règles de l'Art", c'est pas trop ça là bas :P

Aussi, autre illustration du probème, c'est que les ordi etaient des
antiquités (en arrivant j'ai eut un p3-450 avec NT4 et 64 Mo de
RAM...!!! j'ai du me battre un peu ac la technique pr avoir 128Mo...
Et le pire c'est que tout le monde avait ce genre de postes)

J'essaie autant que je peux de les aider, même si mon stage est
désormais fini(un peu trop tôt d'ailleurs puisqu'il viennent
d'entèrement renouveler les PCs...). De toute façon j'y retourne en
février car il me reprennent en Projet de Fin d'Etude

| * faites passer le mot à vos développeur et votre probleme se
| résoud tout seul non? « Pas de doubles quotes dans le SQL, merci
| les gars »;

C'est fait ça

|> C'est pour ça que je cherche une solution plus simple, consistant
|> a configurer la base pour que ça fonctionne directement. C'est
|> plus simple tout de même,car le portage est vraiment long, alors
|> qu'il pourrait prendre qualques heures au plus avec cette simple
|> fonction!
|
|
| 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!

|
| Sincèrement je ne vois qu'une solution: hacker PG, trouver le bout
| de code qui traite les doubles-quotes dans la requete SQL, et
| simplement la by-passer.

mouais pas exactement non plus, mais je vois ce que vous voulez dire,
si je fais un mail ici, c'est pour savoir si je peux eviter ça

|
| Cela nécessite qques connaissances en C, et que vous sachiez
| compiler PG.

ca devrait pouvoir se faire, mais si je pouvais eviter...

|
| Le *gros* hic, c'est que vous devrez maintenir votre vérue par
| rapport aux évolutions de PostgreSQL.
|
| Alors, au final, je vous conseille de rédiger un e.mail explicatif
| de votre problème, en anglais, sur la liste des hackers de
| PostgreSQL, en leur demandant de bien vouloir implémenter votre
| fonctionalité dans PG.

l'ideal serait même que je fournisse un patch, j'ai bien compris

|
| 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

|
|
| Je pense que cela solutionnerait votre problème, et pourrait
| intéresser toutes les personnes qui migrent depuis M$ SQL.

tout a fait! Et ça ouvrirai des "marchés" plus facilement a pg :)

|
|
| Au plaisir de vous lire,
|
|
| Cordialement
|
Vous aussi :)

| PS: je jette un coup d'oeuil dans les sources, des fois que ce soit
| un truc facile à faire, je vous envoie le patch :-)
|
Merchi :) :)
Je vais faire de même une fois que j'aurais fini mon rapport de stage!

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

iD8DBQFBTthni2j5R/FksdIRAnPxAJ4mDndq6VNngM3WfMj9o572mCUSKgCeMqOI
Ugv5biUfjv/hZGn0kETGDxQ=
=IWyf
-----END PGP SIGNATURE-----

-----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-----