Re: Bug in pg_dump
От | Stephen Frost |
---|---|
Тема | Re: Bug in pg_dump |
Дата | |
Msg-id | 20150228160952.GJ29780@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Bug in pg_dump (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Bug in pg_dump
|
Список | 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 по дате отправления: