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