Re: Refactor pg_dump as a library? - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Refactor pg_dump as a library?
Date
Msg-id 570FC88C.6040507@BlueTreble.com
Whole thread Raw
In response to Re: Refactor pg_dump as a library?  (Andreas Karlsson <andreas@proxel.se>)
List pgsql-hackers
On 4/14/16 6:16 AM, Andreas Karlsson wrote:
> On 04/14/2016 12:22 PM, Craig Ringer wrote:
>> I'd find a pg_get_tabledef(...) built-in function more interesting for
>> this particular purpose than pg_dump as a library would be. We already
>> have pg_get_viewdef(...), pg_get_functiondef(...) etc.
>
> I am personally not a fan of the pg_get_Xdef() functions due to their
> heavy reliance on the syscache which feels rather unsafe in combination
> with concurrent DDL. I would not be surprised if we have some low
> probability bugs which cause inconsistent backups there which just has
> not hit enough people yet to have been reported. And this problem will
> only get worse as we reduce the lock level of more DDL.

The other issue specific to pg_dump is it often needs to do something 
different than what pg_get_*def would do to support version upgrades.

I agree that it would be nice to have better DDL generation capabilities 
in the database, but I think the right way to do that is to create the 
pg_dump library and then wrap that as a (version-specific) extension. 
That way you could loan the pg_dump-9.5 extension in a 9.3 database if 
you wanted.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Broken API specification for walrcv_receive
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Pglogical questions and problems