Le 16/11/2016 à 20:05, Tom Lane a écrit :
Arnaud Lesauvage <arnaud.lesauvage@xxxxxxxxx> writes:
[ dump from problematic database ]
OK, thanks for the test case. The problem here is that pg_dump is setting
up a circular dependency that it doesn't know how to break correctly.
You've got a couple of views that are implicitly dependent on the primary
keys of their underlying tables, because they use a GROUP BY the primary
key without also grouping by other columns they use post-grouping. That
means that pg_dump has to dump the view definition after the creation of
the primary key, but it also needs to put the view out sooner than that
for other reasons. It manages to deal with that okay in the default mode,
but when you have --clean in there, it ends up generating an illegal DROP
RULE command.
All right, at least I'm glad that I did not miss something obvious.
This is something we ought to fix, but it's not exactly trivial to do.
In the meantime I'd suggest changing the view definitions to not assume
that the underlying tables have primary keys. It looks like in
view_temp_export_geo_recherche_extra_sites_projets you need to add
c.official_language_id to the GROUP BY, and similarly in
view_temp_export_geo_recherche_offtrad_sites.
Thanks for the tip ! I'll try this ASAP.
I never "GROUP BY" primary keys only, so I can consider this as an error
that needs fixing. I did not even know that this was valid SQL to be honest.
Thanks a lot for your help !
Regards
--
Arnaud
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
