From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: pg_dump 9.6 doesn't honour pg_extension_config_dump for sequences |
Date: | 2017-01-19 13:46:40 |
Message-ID: | 20170119134640.GN18360@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Michael,
* Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
> As far as I can see, the code path to dumpSequenceData() is taken
> correctly for such a sequence. processExtensionTables() creates a
> dataObj using makeTableDataInfo() only for sequences in extensions
> that are dumpable. So I have been wondering what's happening for some
> time, until I noticed that:
> --- a/src/bin/pg_dump/pg_dump.c
> +++ b/src/bin/pg_dump/pg_dump.c
> @@ -15671,7 +15671,7 @@ dumpSequenceData(Archive *fout, TableDataInfo *tdinfo)
> appendPQExpBuffer(query, ", %s, %s);\n",
> last, (called ? "true" : "false"));
>
> - if (tbinfo->dobj.dump & DUMP_COMPONENT_DATA)
> + if (tdinfo->dobj.dump & DUMP_COMPONENT_DATA)
> ArchiveEntry(fout, nilCatalogId, createDumpId(),
> tbinfo->dobj.name,
> tbinfo->dobj.namespace->dobj.name,
> Not sure if I need to laugh or cry. Attached is a patch with the fix
> and new regression tests.
Yeah, that looks like the right answer and matches how dumpTableData
handles this, which is also why that's working correctly.
I don't particularly like this arrangement though. This works because:
getTables() will create the entry for the sequence and call
selectDumpableTable(), which calls checkExtensionMembership(), which
will set the dump flags to ACL | SECLABEL | POLICY, and then
getTableData() will skip adding a data entry for it because DATA isn't
set, allowing processExtensionTables() to add the DATA entry later for
config tables/sequences.
Now that we've got the ability to indicate which pieces of a object
should be dumped, however, it seems like we could just check in
checkExtensionMembership() if it's a config table and set DATA then if
it is, possibly removing the need for processExtensionTables() entirely.
That's really future-work, but I wanted to mention my thoughts here in
case someone wants to work on it, or I might once I've cleared off the
other things on my plate. For now, I'll go ahead and commit your
suggested fix, and thanks for including a new regression test to cover
this.
Thanks again!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2017-01-19 18:53:31 | Re: pg_dump 9.6 doesn't honour pg_extension_config_dump for sequences |
Previous Message | Devrim Gündüz | 2017-01-19 13:33:50 | Re: installation of older versions |