From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net>, depesz(at)depesz(dot)com, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [GENERAL] pg_dump -s dumps data?! |
Date: | 2012-02-10 19:54:27 |
Message-ID: | 22582.1328903667@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
I wrote:
> Now, back to the original subject of this thread: both HEAD and 9.1 are
> now operating as designed, in that they will dump the (user-provided
> portion of the) contents of an extension config table whenever that
> extension is dumped, even if --schema is specified.
Or so I thought, anyway. Further experimentation with despez's example
shows that in HEAD, --schema is still able to block dumping of extension
config table contents, and the reason appears to be commit
a4cd6abcc901c1a8009c62a27f78696717bb8fe1, which added yet another set
of filtering conditions in a poorly chosen place; or possibly I should
say it made arbitrary changes in the definition of the --schema switch.
That patch needs some rethinking too, though I'm not sure what yet.
I also note that his example shows that if you have a selective dump
(say, with a -t switch), config table contents will be dumped even when
the owning extension is not. This seems like a pretty clear bug:
getExtensionMembership should not be creating TableDataInfo objects for
extension config tables if the owning extension is not to be dumped.
Barring objections, I'll go fix and back-patch that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Vincent Veyron | 2012-02-10 19:56:24 | Re: Strategy for Primary Key Generation When Populating Table |
Previous Message | Steve Clark | 2012-02-10 19:33:05 | Re: " " around fields with psql |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2012-02-10 19:59:36 | Re: Core Extensions relocation |
Previous Message | Alex Hunsaker | 2012-02-10 19:53:05 | Re: pl/perl and utf-8 in sql_ascii databases |