Re: [pgsql-fr-generale] Reformatage inopiné des requêtes dans les vues

Bonjour,

Le 9 mars 2016 6:17 PM, "Pierre Chevalier Géologue" <
pierrechevaliergeol(at)free(dot)fr> a écrit :
>
> Bonjour,
>
> Étant un peu neuf dans la communauté PostgreSQL et encore un peu timidou,
j'ai choisi de poster d'abord cette question ici, dans la langue de
Molière, afin que toutes les nuances de ma langue maternelle puissent être
perçues. J'ai bien conscience que ce message aurait plus sa place sur les
listes anglophones: plus tard, quand je serai suffisamment aguerri,
j'oserai m'y exprimer.
>
> Voilà mon souci: quand je fais une requête qui me donne satisfaction et
que je veux l'immortaliser en tant que vue, je constate, depuis longtemps,
qu'une fois stockée, elle est quelque peu modifiée.
>
>
> Un exemple, avec une table qui contient des coordonnées de points, et une
vue qui crée automagiquement des entités géographiques ponctuelles liées
dynamiquement aux coordonnées des attributs de la table (un peu
l'équivalent des bons vieux "event themes" de chez Arcview).
>
> La table, avec quelques coordonnées (les deux derniers meetups où je me
suis rendus):
> CREATE TABLE coords (id SERIAL PRIMARY KEY, x float, y float, z float,
srid integer);
>
> INSERT INTO coords (x, y, z) VALUES
> (1.3635448815, 43.6602665901, 196.50),
> (1.5070172183, 43.5418566310, 193.80);
> UPDATE coords SET srid = 4326;
>
>
> Puis la vue:
>
> CREATE VIEW coords_points AS
> SELECT *,
> GeomFromewkt(
> 'SRID='|| srid ||';
> POINT(' ||
> x || ' ' ||
> y || ' ' ||
> z ||
> ')'
> )
> FROM coords;
>
>
> Vous aurez noté la mise en forme, qui met ici en évidence la construction
du WKT de la requête: c'est essentiellement à des fins didactiques, quand
je fais des cours. Je fais des mises en forme purement cosmétiques, pour
faciliter la relecture, assez systématiquement.
>
> Mais quand je consulte la définition de ma vue:
>
> pierre(at)bdexplo=> \d+ coords_points
> Vue « pierre.coords_points »
> Colonne | Type | Modificateurs | Stockage | Description
> --------------+------------------+---------------+----------+-------------
> id | integer | | plain |
> x | double precision | | plain |
> y | double precision | | plain |
> z | double precision | | plain |
> srid | integer | | plain |
> geomfromewkt | geometry | | main |
> Définition de la vue :
> SELECT coords.id,
> coords.x,
> coords.y,
> coords.z,
> coords.srid,
> geomfromewkt(((((((('SRID='::text || coords.srid) || ';POINT('::text)
|| coords.x) || ' '::text) || coords.y) || ' '::text) || coords.z) ||
')'::text) AS geomfromewkt
> FROM coords;
>
>
> , patatras: non solum ma belle (c'est subjectif) mise en forme a fichu le
camp, sed etiam il y a des cast que je trouve assez curieux, et des
parenthèses que je jugerais un peu superfétatoires. Et je trouve ça assez
illisible, pour la partie construction du WKT.
>
> Je trouvais cela frustrant, et gardais donc toutes mes définitions de
vues dans des fichiers à part, les rejouant, quand le besoin s'en faisait
sentir. Mais cela s'est avéré fort embêtant dans certains cas, par exemple
quand d'autres instances de la même base, déployées chez des clients,
avaient eu des changements dans les vues. Dans ces cas, faire des diffs sur
les sources était un peu, laborieux, dirais-je.
>
> J'ai parcouru ce fil:
>
http://postgresql.nabble.com/Preserving-the-source-code-of-views-td5775163.html
> et j'ai bien pigé que postgres ne stockait en interne qu'une version
remoulinée du SQL qui lui était passé.
>
> D'où mes questionnements; déjà: la situation a-t-elle évolué depuis
octobre 2013, date de la fin de la conversation mentionnée ci-dessus, ou
pas?
> Je me demandais s'il n'y aurait pas moyen de stocker à la fois le SQL
pur, joliment formaté, dans un coin, tel qu'il a été rédigé par son auteur
humain, ET la définition telle qu'on la trouve maintenant, fournie par, si
j'ai bien suivi, le biais de pg_get_viewdef().
>
> En espérant avoir été à peu près clair.
>

La solution généralement proposée est de placer les requetes DDL dans un
outil de gestion de sources (git par exemple).