Re: Bug in pg_dump - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Bug in pg_dump
Date
Msg-id 20150228160952.GJ29780@tamriel.snowman.net
Whole thread Raw
In response to Re: Bug in pg_dump  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Bug in pg_dump  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
Michael,

* Michael Paquier (michael.paquier@gmail.com) wrote:
> +            /*
> +             * Query all the foreign key dependencies for all the extension
> +             * tables found previously. Only tables whose data need to be
> +             * have to be tracked.
> +             */
> +            appendPQExpBuffer(query2,
> +                      "SELECT conrelid, confrelid "
> +                      "FROM pg_catalog.pg_constraint "
> +                      "WHERE contype = 'f' AND conrelid IN (");
> +
> +            for (j = 0; j < nconfigitems; j++)
> +            {

[...]

Instead of building up a (potentially) big list like this, couldn't we
simply join against pg_extension and check if conrelid = ANY (extconfig)
instead, based on the extension we're currently processing?

eg:
    appendPQExpBuffer(query2,              "SELECT conrelid, confrelid "              "FROM pg_catalog.pg_constraint,
pg_extension"              "WHERE contype = 'f' AND extname = '%s' AND conrelid = ANY (extconfig)",
fmtId(curext->dobj.name));

This seemed to work just fine for me, at least, and reduces the size of
the patch a bit further since we don't need the loop that builds up the
ids.

> 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.
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Bug in pg_dump
Next
From: Tom Lane
Date:
Subject: Re: star schema and the optimizer