On Wed, May 14, 2014 at 10:58 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmonc...@gmail.com> writes:
>> On Wed, May 14, 2014 at 9:44 AM, Tom Lane <t...@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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to