Horton

Re: pg_dump -s dumps data?!

Adrian Klaver <adrian.klaver@gmail.com>

View thread
From: Adrian Klaver <adrian.klaver@gmail.com>
To: depesz@depesz.com
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-general@postgresql.org
Date: 2012-01-30T17:51:58Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add --section option to pg_dump and pg_restore.

  2. Add --exclude-table-data option to pg_dump.

On 01/30/2012 09:45 AM, hubert depesz lubaczewski wrote:
> On Mon, Jan 30, 2012 at 09:43:46AM -0800, Adrian Klaver wrote:
>> On 01/30/2012 09:23 AM, hubert depesz lubaczewski wrote:
>>
>>>
>>> I think I explained it in previous mails, and if not - sorry, but
>>> I clearly can't explain good enough - the point is that with the way how
>>> extensions now work, they are useless for providing way to create
>>> tables that will store data, in case you would ever want dump without
>>> this data.
>>
>> So in summary; if an extension creates a user table you want access
>> to that table(schema and data) via pg_dump, outside the extension
>> mechanism, without resorting to marking it as a configuration table.
>> Is that correct ?
>
> no.
> I want to be able to do both:
> 1. dump the data for the table
> 2. dump structure of other tables
> but not in the same file.

Actually that was what I was saying:)

"..via pg_dump, outside the extension mechanism.."

"..without resorting to marking it as a configuration table.."

Currently the extension mechanism is getting in the way of 1 & 2 above. 
What you want is for pg_dump to ignore the extension dependency process 
when you explicitly name a table and the operation on it.


>
> Best regards,
>
> depesz
>


-- 
Adrian Klaver
adrian.klaver@gmail.com