Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] pg_dump -s dumps data?!

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, depesz(at)depesz(dot)com, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] pg_dump -s dumps data?!
Date: 2012-01-31 23:07:51
Message-ID: 12981.1328051271@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> writes:
> On 01/31/2012 04:36 AM, Robert Haas wrote:
>> On Mon, Jan 30, 2012 at 11:18 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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 friendly
>>> towards the idea of an extension that creates a table that's meant
>>> solely to hold user data --- you'd have to mark it as "config" which
>>> seems a bit unfortunate terminology for that case.  Is it important to
>>> do something about that, and if so what?

>> Is this anything more than a naming problem?

> Seems to me that would be dependent on what the future plans are for the 
> extension mechanism.

My thought exactly --- maybe it's only a minor cosmetic issue that will
affect few people, or maybe this will someday be a major use-case.
I don't know.  I was hoping Dimitri had an opinion.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-01-31 23:43:41
Subject: Re: Should we add crc32 in libpgport?
Previous:From: Tom LaneDate: 2012-01-31 23:04:54
Subject: Re: Index-only scan performance regression

pgsql-general by date

Next:From: Andrew DunstanDate: 2012-02-01 04:10:32
Subject: Re: [GENERAL] pg_dump -s dumps data?!
Previous:From: Alban HertroysDate: 2012-01-31 22:51:33
Subject: Re: Help speeding up a left join aggregate

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group