Re: Bug in pg_dump

Michael,

* Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
> The thing is that we must absolutely wait for *all* the TableInfoData
> of all the extensions to be created because we need to mark the
> dependencies between them, and even my last patch, or even with what
> you are proposing we may miss tracking of FK dependencies between
> tables in different extensions. This has little chance to happen in
> practice, but I think that we should definitely get things right.
> Hence something like this query able to query all the FK dependencies
> with tables in extensions is more useful, and it has no IN clause:

Ah, yes, extensions can depend on each other and so this could
definitely happen. The current issue is around postgis, which by itself
provides three different extensions.

> + appendPQExpBuffer(query,
> + "SELECT conrelid, confrelid "
> + "FROM pg_constraint "
> + "LEFT JOIN pg_depend ON (objid = confrelid) "
> + "WHERE contype = 'f' "
> + "AND refclassid = 'pg_extension'::regclass "
> + "AND classid = 'pg_class'::regclass;");

I'm trying to figure out why this is a left join..?

> >> Subject: [PATCH 2/3] Make prove_check install contents of current directory as well
> >
> > This is really an independent thing, no? I don't see any particular
> > problem with it, for my part.
>
> Yes, that's an independent thing, but my guess is that it would be
> good to have a real test case this time to be sure that this does not
> break again, at least on master where test/modules is an ideal place.

No objection to it, just pointing out that it's independent.

> Attached are updated patches, the fix of pg_dump can be easily
> cherry-picked down to 9.2. For 9.1 things are changed a bit because of
> the way SQL queries are run, still patches are attached for all the
> versions needed. I tested as well the fix down to this version 9.1
> using the test case dump_test.

Will review.

Thanks!

Stephen