On Wed, May 14, 2014 at 10:58 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Wed, May 14, 2014 at 9:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> The reason that that project has gone untouched for upwards of ten years
>>> is that it's not just a large coding project, but involves a lot of
>>> complex API design with uncertain goals. It's not very clear what
>>> features people would want from a "pg_dump library", though one capability
>>> that gets mentioned often is the ability to extract the SQL definition
>>> for a single object.
>
>> Personally I'd prefer the creation of definitional SQL be moved out of
>> pg_dump and into the database proper via something like
>> 'pg_sql_definition(oid)' or something like that.
>
> Well, that's just a different way of packaging a library, no? It doesn't
> make the library-API problems any less difficult. If anything, it makes
> things even harder, because now you have to consider version skew between
> pg_dump and the server. And if you get any API details wrong you have
> no ability to change them till the next major release cycle.
>
> While we might someday do it like that, I'd think it foolish to proceed
> with such an approach until we had a proven library API design on the
> client side. The costs of iterating there are a lot less.
Yeah -- Andres said it even more cleanly: for forward upgrades you'd
need to communicate with both versioned backends to produce a dump.
That's not a complete deal breaker but definitely a lot more complex
than I was thinking.
merlin