Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
>>> pg_dump | pg_restore
>>> pg_export | psql
>> While I agree that this idea - when implemented - would be nicer in
>> practically every way, I'm not sure I want to volunteer to do all the
>> necessary work.
> What I think needs to happen now is a commiter's buy in that we want to
> get there at some point and that your current patch is not painting us
> into any corner now. So that we can accept it and have a documented path
Just stumbled accross this message while reading some older threads
about the current topic:
Where Robert Treat said:
> I've both enjoyed reading this thread and seeing this wheel reinvented
> yet again, and wholeheartedly +1 the idea of building this directly
> into pg_dump. (The only thing better would be to make everything thing
> sql callable, but that's a problem for another day).
I know Andrew has been working on his "Retail DDL" project which is
basically a bunch of server-side functions that spits out SQL object
definitions. Andrew, were you able to make progress on that project?
On the other hand, pg_dump -Fs still is something I would like to have
as a complement to Andrew's facility.
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
In response to
pgsql-hackers by date
|Next:||From: Dimitri Fontaine||Date: 2012-11-19 14:22:31|
|Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL|
|Previous:||From: Pavel Stehule||Date: 2012-11-19 13:17:33|
|Subject: review: Reduce palloc's in numeric operations|