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. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
