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, any
Andrew Dunstan 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
> it in those tw
On 02/07/2012 02:56 PM, Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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 creation of a TableDa
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:
http://ww
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 writes:
> Perhaps a better way of dealing with this is providing a way of dumping
> extensions explicitly. Then you could say:
>
> pg_dump --extension=postgis -s
On 01/31/2012 05:48 PM, Tom Lane wrote:
Andrew Dunstan 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 br
Adrian Klaver writes:
> On 01/31/2012 04:36 AM, Robert Haas wrote:
>> On Mon, Jan 30, 2012 at 11:18 PM, Tom Lane 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 friendly
>>> towards the idea of an
Andrew Dunstan 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 enumerate its sho
On 01/31/2012 04:36 AM, Robert Haas wrote:
On Mon, Jan 30, 2012 at 11:18 PM, 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 i
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 sho
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
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, w
On Mon, Jan 30, 2012 at 11:18 PM, 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 b
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
[ Note: please follow-up to pgsql-hackers not pgsql-general; I think
this discussion needs to move there ]
hubert depesz lubaczewski 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
>> options you're usi
17 matches
Mail list logo
