Re: Reformatage inopiné des requêtes dans les vues

From: Pierre Chevalier Géologue <pierrechevaliergeol(at)free(dot)fr>
To: pgsql-fr-generale <pgsql-fr-generale(at)postgresql(dot)org>
Subject: Re: Reformatage inopiné des requêtes dans les vues
Date: 2016-03-09 18:59:34
Message-ID: 56E07296.6030501@free.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Bonsoir,

Le 09/03/2016 18:50, Jean-Louis Louër a écrit :
> pourquoi ne pas faire dans toutes les instances, un :
> pg_dump -s mabase > export.sql
> et ainsi pouvoir comparer les fichiers produits.

C'est un peu ce que je faisais, oui: soit je faisais des \d
lavuesuspecte, soit des pg_dump en y greppant à l'envi. Mais c'était
tout de même très pénible à lire/comprendre.

L'exemple que j'ai pris où je construis dynamiquement un WKT se
reproduit souvent, avec des choses parfois un peu plus touffues, du genre:

CREATE OR REPLACE VIEW dh_traces_3d_20136 AS
SELECT *,
GeomFromEWKT(
'SRID=' || srid ||
';LINESTRING (' ||
x || ' ' ||
y || ' ' ||
z ||
', ' ||
x1 || ' ' ||
y1 || ' ' ||
z1 ||
')'
)
FROM (
SELECT *,
x + length * cos((dip_hz / 180) * pi())
* sin((azim_ng / 180) * pi())
AS x1,
y + length * cos((dip_hz / 180) * pi())
* cos((azim_ng / 180) * pi())
AS y1,
z - length * sin((dip_hz / 180) * pi())
AS z1
FROM dh_collars
WHERE srid = 20136
) tmp
ORDER BY tmp.id;

(il est possible que le formatage soit resté correct via l'émail; je ne
me limite bien souvent pas aux 80 caractères de largeur usuels)

Ce qui donne, quand on regarde la sortie du pg_dump:

CREATE VIEW dh_traces_3d_20136 AS
SELECT tmp.id,
tmp.shid,
tmp.location,
tmp.profile,
tmp.srid,
tmp.x,
tmp.y,
tmp.z,
tmp.azim_ng,
tmp.azim_nm,
tmp.dip_hz,
tmp.dh_type,
tmp.date_start,
tmp.contractor,
tmp.geologist,
tmp.length,
tmp.nb_samples,
tmp.comments,
tmp.completed,
tmp.numauto,
tmp.date_completed,
tmp.opid,
tmp.purpose,
tmp.x_local,
tmp.y_local,
tmp.z_local,
tmp.accusum,
tmp.id_pject,
tmp.x_pject,
tmp.y_pject,
tmp.z_pject,
tmp.topo_survey_type,
tmp.db_update_timestamp,
tmp.username,
tmp.datasource,
tmp.x1,
tmp.y1,
tmp.z1,
public.geomfromewkt((((((((((((((('SRID='::text || tmp.srid) ||
';LINESTRING ('::text) || tmp.x) || ' '::text) || tmp.y) || ' '::text)
|| tmp.z) || ', '::text) || tmp.x1) || ' '::text) || tmp.y1) || '
'::text) || tmp.z1) || ')'::text)) AS geomfromewkt
FROM ( SELECT dh_collars.id,
dh_collars.shid,
dh_collars.location,
dh_collars.profile,
dh_collars.srid,
dh_collars.x,
dh_collars.y,
dh_collars.z,
dh_collars.azim_ng,
dh_collars.azim_nm,
dh_collars.dip_hz,
dh_collars.dh_type,
dh_collars.date_start,
dh_collars.contractor,
dh_collars.geologist,
dh_collars.length,
dh_collars.nb_samples,
dh_collars.comments,
dh_collars.completed,
dh_collars.numauto,
dh_collars.date_completed,
dh_collars.opid,
dh_collars.purpose,
dh_collars.x_local,
dh_collars.y_local,
dh_collars.z_local,
dh_collars.accusum,
dh_collars.id_pject,
dh_collars.x_pject,
dh_collars.y_pject,
dh_collars.z_pject,
dh_collars.topo_survey_type,
dh_collars.db_update_timestamp,
dh_collars.username,
dh_collars.datasource,
((dh_collars.x)::double precision +
(((dh_collars.length)::double precision * cos((((dh_collars.dip_hz /
(180)::numeric))::double precision * pi()))) * sin((((dh_collars.azim_ng
/ (180)::numeric))::double precision * pi())))) AS x1,
((dh_collars.y)::double precision +
(((dh_collars.length)::double precision * cos((((dh_collars.dip_hz /
(180)::numeric))::double precision * pi()))) * cos((((dh_collars.azim_ng
/ (180)::numeric))::double precision * pi())))) AS y1,
((dh_collars.z)::double precision -
((dh_collars.length)::double precision * sin((((dh_collars.dip_hz /
(180)::numeric))::double precision * pi())))) AS z1
FROM dh_collars
WHERE (dh_collars.srid = 20136)) tmp
ORDER BY tmp.id;

C'est certes joliment présenté, mais bon, ça ne correspond pas à la
logique que j'avais initialement exprimée.
Et là, à détricoter, ça commence à devenir un peu plus velu.
L'absence de la conservation du joker * au début de la définition de la
vue est aussi un peu embêtant, dans la mesure où certains clients
rajoutaient des champs (ce qui ne simplifiait pas les choses). Avoir les
champs du * non "expanded" m'aurait ôté quelque peine dans les
traitements des diffs.

À+
Pierre
--
____________________________________________________________________________
Pierre Chevalier
PChGEI: Pierre Chevalier Géologue Et Informaticien
Partenaire DALIBO
Mesté Duran
32100 Condom
Tél+fax : 09 75 27 45 62
06 37 80 33 64
Émail : pierrechevaliergeolCHEZfree.fr
icq# : 10432285
jabber: pierre(dot)chevalier1967(at)jabber(dot)fr
http://pierremariechevalier.free.fr/pierre_chevalier_geologue
____________________________________________________________________________

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

In response to

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Pierre Chevalier Géologue 2016-03-09 19:02:56 Re: Reformatage inopiné des requêtes dans les vues
Previous Message Éric de la Musse 2016-03-09 18:37:20 Re: Reformatage inopiné des requêtes dans les vues