On 03/21/2014 09:38 AM, Robert Haas wrote:
> On Thu, Mar 20, 2014 at 11:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Craig Ringer <craig@2ndquadrant.com> writes:
>>> Here's how I think it needs to look:
>>> [ move all the functionality to the backend ]
>> Of course, after you've done all that work, you've got something that is
>> of exactly zero use to its supposed principal use-case, pg_dump. pg_dump
>> will still have to support server versions that predate all these fancy
>> new dump functions, and that pretty much ensures that most of pg_dump's
>> core functionality will still be on the client side. Or, if you try to
>> finesse that problem by making sure the new server APIs correspond to
>> easily-identified pieces of pg_dump code, you'll probably end up with APIs
>> that nobody else wants to use :-(.
> It's worse than that. If you put all the logic in the server, then a
> dump taken on an older version won't be able to quote keywords added
> in the newer version. Go directly to fail.
>
Yeah. This tantalizing project has been looked at several times and
found to be a viper's nest.
What would be useful for many purposes, and is a long-standing project
of mine that I still haven't found time to make progress on, is that the
server should contain functions to produce the creation SQL for all its
own objects, free of the locks that pg_dump requires for consistency.
That would be a great SoC project, incidentally. I'd even volunteer to
mentor that one.
cheers
andrew