Re: [HACKERS] QSoC proposal: Rewrite pg_dump and pg_restore

2014-03-21 Thread Alvaro Herrera
Andrew Dunstan escribió: > 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 requi

Re: [HACKERS] QSoC proposal: Rewrite pg_dump and pg_restore

2014-03-21 Thread Andrew Dunstan
On 03/21/2014 09:38 AM, Robert Haas wrote: On Thu, Mar 20, 2014 at 11:09 PM, Tom Lane wrote: Craig Ringer 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 t

Re: [HACKERS] QSoC proposal: Rewrite pg_dump and pg_restore

2014-03-21 Thread Robert Haas
On Thu, Mar 20, 2014 at 11:09 PM, Tom Lane wrote: > Craig Ringer 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,

Re: [HACKERS] QSoC proposal: Rewrite pg_dump and pg_restore

2014-03-21 Thread Marcin Mańk
On Fri, Mar 21, 2014 at 4:09 AM, Tom Lane wrote: > Craig Ringer 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

Re: [HACKERS] QSoC proposal: Rewrite pg_dump and pg_restore

2014-03-20 Thread Craig Ringer
On 03/21/2014 11:09 AM, Tom Lane wrote: > Craig Ringer 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.

Re: [HACKERS] QSoC proposal: Rewrite pg_dump and pg_restore

2014-03-20 Thread Tom Lane
Craig Ringer 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

Re: [HACKERS] QSoC proposal: Rewrite pg_dump and pg_restore

2014-03-20 Thread Craig Ringer
On 03/21/2014 09:28 AM, Robert Haas wrote: > On Tue, Mar 18, 2014 at 8:41 PM, Alexandr wrote: >> Rewrite (add) pg_dump and pg_restore utilities as libraries (.so, .dll & >> .dylib) > > This strikes me as (1) pretty vague and (2) probably too hard for a > summer project. > > I mean, getting the e

Re: [HACKERS] QSoC proposal: Rewrite pg_dump and pg_restore

2014-03-20 Thread Robert Haas
On Tue, Mar 18, 2014 at 8:41 PM, Alexandr wrote: > Rewrite (add) pg_dump and pg_restore utilities as libraries (.so, .dll & > .dylib) This strikes me as (1) pretty vague and (2) probably too hard for a summer project. I mean, getting the existing binaries to build libraries that you can call wit

[HACKERS] QSoC proposal: Rewrite pg_dump and pg_restore

2014-03-18 Thread Alexandr
Hello! Here is the text of my proposal which I've applied to GSoC. (and link https://docs.google.com/document/d/1s-Q4rzEysPxo-dINsk_eKFJOBoVjNYDrQ-Oh75gtYEM/edit?usp=sharing) Any suggestions and comments are welcome. * PostgreSQL GSoC 2014 proposal Project name Rewrite (add) pg_dump and pg_