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,
Andrew Dunstan and...@dunslane.net writes:
OK, in this version we simply suppress creation of the TableDataInfo
object if it's not wanted.
I applied this with some further adjustments.
I actually removed the code from
makeTableDataInfo - there are only two places it gets called and doing
Andrew Dunstan and...@dunslane.net writes:
On 01/31/2012 11:10 PM, Andrew Dunstan wrote:
Here's a possible patch for the exclude-table-data problem along the
lines you suggest.
Should I apply this?
I'm not happy with this yet. My core complaint is that pg_dump used to
consider that
On 02/07/2012 02:56 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 01/31/2012 11:10 PM, Andrew Dunstan wrote:
Here's a possible patch for the exclude-table-data problem along the
lines you suggest.
Should I apply this?
I'm not happy with this yet. My core complaint is
On 01/31/2012 11:10 PM, Andrew Dunstan wrote:
Here's a possible patch for the exclude-table-data problem along the
lines you suggest.
Should I apply this?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Wed, Feb 01, 2012 at 10:02:14PM +0100, Dimitri Fontaine wrote:
The case for a table that is partly user data and partly extension data
is very thin, I think that if I had this need I would use inheritance
and a CHECK(user_data is true/false) constraint to filter the data.
definitely agree.
Hi,
Sorry to be late in the thread, I'm too busy right now. Cédric called
it to my immediate attention though.
Martijn van Oosterhout klep...@svana.org writes:
Perhaps a better way of dealing with this is providing a way of dumping
extensions explicitly. Then you could say:
pg_dump
On Mon, Jan 30, 2012 at 11:18:31PM -0500, Tom Lane wrote:
I don't recall that we thought very hard about what should happen when
pg_dump switches are used to produce a selective dump, but ISTM
reasonable that if it's user data then it should be dumped only if
data in a regular user table would
On Mon, Jan 30, 2012 at 11:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't recall that we thought very hard about what should happen when
pg_dump switches are used to produce a selective dump, but ISTM
reasonable that if it's user data then it should be dumped only if
data in a regular user
On 01/30/2012 11:18 PM, Tom Lane wrote:
[ example showing pg_dump's odd behavior for extension config tables ]
[ traces through that with gdb... ]
As I suspected, the behavioral change from 9.1 to HEAD is not
intentional. It is an artifact of commit
7b070e896ca835318c90b02c830a5c4844413b64,
On Mon, Jan 30, 2012 at 11:18:31PM -0500, Tom Lane wrote:
I don't recall that we thought very hard about what should happen when
pg_dump switches are used to produce a selective dump, but ISTM
reasonable that if it's user data then it should be dumped only if
data in a regular user table would
On 01/31/2012 03:02 PM, Martijn van Oosterhout wrote:
On Mon, Jan 30, 2012 at 11:18:31PM -0500, Tom Lane wrote:
I don't recall that we thought very hard about what should happen when
pg_dump switches are used to produce a selective dump, but ISTM
reasonable that if it's user data then it
On 01/31/2012 04:36 AM, Robert Haas wrote:
On Mon, Jan 30, 2012 at 11:18 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I don't recall that we thought very hard about what should happen when
pg_dump switches are used to produce a selective dump, but ISTM
reasonable that if it's user data then it should
Andrew Dunstan and...@dunslane.net writes:
On 01/30/2012 11:18 PM, Tom Lane wrote:
As I suspected, the behavioral change from 9.1 to HEAD is not
intentional. It is an artifact of commit
7b070e896ca835318c90b02c830a5c4844413b64, which is almost, but not
quite, entirely broken. I won't
Adrian Klaver adrian.kla...@gmail.com writes:
On 01/31/2012 04:36 AM, Robert Haas wrote:
On Mon, Jan 30, 2012 at 11:18 PM, Tom Lanet...@sss.pgh.pa.us wrote:
What's not apparent to me is whether there's an argument for doing more
than that. It strikes me that the current design is not very
On 01/31/2012 05:48 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 01/30/2012 11:18 PM, Tom Lane wrote:
As I suspected, the behavioral change from 9.1 to HEAD is not
intentional. It is an artifact of commit
7b070e896ca835318c90b02c830a5c4844413b64, which is almost, but
[ Note: please follow-up to pgsql-hackers not pgsql-general; I think
this discussion needs to move there ]
hubert depesz lubaczewski dep...@depesz.com writes:
On Mon, Jan 30, 2012 at 11:30:51AM -0500, Tom Lane wrote:
That is way too vague for my taste, as you have not shown the pg_dump
17 matches
Mail list logo
