Thread: -f
In pgAdmin we use pg_dump's -f option to write backup files. The IO streams are redirected to display status and errors etc. in the GUI. In order to enhance the interface to allow backup of entire clusters as well as role and tablespace definitions, we need to be able to get pg_dumpall to write it's output directly to a file in the same way, because we cannot redirect the child pg_dump IO streams (which also means we may miss errors, but I need to think about that some more). As far as I can see, adding a -f option to pg_dumpall should be straight forward, the only issue being that we'd need to pass pg_dump an additional (undocumented?) option to tell it to append to the output file instead of writing it as normal. Any thoughts or better ideas? Regards, Dave.
> As far as I can see, adding a -f option to pg_dumpall should be straight
> forward, the only issue being that we'd need to pass pg_dump an
> additional (undocumented?) option to tell it to append to the output
> file instead of writing it as normal.
>
> Any thoughts or better ideas?
Yeah :) Getting rid of pg_dumpall entirely and merging it into pg_dump.
It is kind of silly that we have two different versions. Although that
may be more work than you were considering.
Joshua D. Drake
>
> Regards, Dave.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Dave Page wrote: > In pgAdmin we use pg_dump's -f option to write backup files. The IO > streams are redirected to display status and errors etc. in the GUI. > > In order to enhance the interface to allow backup of entire clusters as > well as role and tablespace definitions, we need to be able to get > pg_dumpall to write it's output directly to a file in the same way, > because we cannot redirect the child pg_dump IO streams (which also > means we may miss errors, but I need to think about that some more). > > As far as I can see, adding a -f option to pg_dumpall should be straight > forward, the only issue being that we'd need to pass pg_dump an > additional (undocumented?) option to tell it to append to the output > file instead of writing it as normal. > > Any thoughts or better ideas? > > This seems a bit like piecemeal reform. Here are some things I'd like to see that affect this area: . merge pg_dump and pg_dumpall (e.g. add a flag to pg_dump that says do the lot) . multi-db non-text dumps And while we're about it, can we teach pg_restore to handle text dumps? Even if it just transparently called psql it would be nice. cheers andrew
On Friday 05 January 2007 09:40, Andrew Dunstan wrote: > Dave Page wrote: > > In pgAdmin we use pg_dump's -f option to write backup files. The IO > > streams are redirected to display status and errors etc. in the GUI. > > > > In order to enhance the interface to allow backup of entire clusters as > > well as role and tablespace definitions, we need to be able to get > > pg_dumpall to write it's output directly to a file in the same way, > > because we cannot redirect the child pg_dump IO streams (which also > > means we may miss errors, but I need to think about that some more). > > > > As far as I can see, adding a -f option to pg_dumpall should be straight > > forward, the only issue being that we'd need to pass pg_dump an > > additional (undocumented?) option to tell it to append to the output > > file instead of writing it as normal. > > > > Any thoughts or better ideas? > > This seems a bit like piecemeal reform. Here are some things I'd like to > see that affect this area: > > . merge pg_dump and pg_dumpall (e.g. add a flag to pg_dump that says do > the lot) > . multi-db non-text dumps > > And while we're about it, can we teach pg_restore to handle text dumps? > Even if it just transparently called psql it would be nice. +1 on on having pg_restore work with text dumps. > > cheers > > andrew > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org
On Fri, Jan 05, 2007 at 12:40:20PM -0500, Andrew Dunstan wrote: > Dave Page wrote: > >In pgAdmin we use pg_dump's -f option to write backup files. The IO > >streams are redirected to display status and errors etc. in the GUI. > > > >In order to enhance the interface to allow backup of entire clusters as > >well as role and tablespace definitions, we need to be able to get > >pg_dumpall to write it's output directly to a file in the same way, > >because we cannot redirect the child pg_dump IO streams (which also > >means we may miss errors, but I need to think about that some more). > > > >As far as I can see, adding a -f option to pg_dumpall should be straight > >forward, the only issue being that we'd need to pass pg_dump an > >additional (undocumented?) option to tell it to append to the output > >file instead of writing it as normal. > > > >Any thoughts or better ideas? > > > This seems a bit like piecemeal reform. Here are some things I'd like to > see that affect this area: > > . merge pg_dump and pg_dumpall (e.g. add a flag to pg_dump that says do > the lot) > . multi-db non-text dumps > > And while we're about it, can we teach pg_restore to handle text dumps? > Even if it just transparently called psql it would be nice. +1 on all of this :) Cheers, D (who can contribute code once we've agreed on what it should do) -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
David Fetter wrote: >> This seems a bit like piecemeal reform. Here are some things I'd like to >> see that affect this area: >> >> . merge pg_dump and pg_dumpall (e.g. add a flag to pg_dump that says do >> the lot) >> . multi-db non-text dumps >> >> And while we're about it, can we teach pg_restore to handle text dumps? >> Even if it just transparently called psql it would be nice. > > +1 on all of this :) Hmm, well I have no interest in the latter at present, but assuming the powers that be will allow me some time to do so, I will look at merging pg_dump and pg_dumpall as that seems to be the way people want to go. I'd also like to tweak the options for global objects to allow roles and tablespaces to be dumped seperately from each other if no-one objects. > Cheers, > D (who can contribute code once we've agreed on what it should do) Cool - fancy picking up the multi-db non text and pg_restore bits if I do the former? Regards, Dave.
Andreas Pflug wrote: > Dave Page wrote: >> In pgAdmin we use pg_dump's -f option to write backup files. The IO >> streams are redirected to display status and errors etc. in the GUI. >> >> In order to enhance the interface to allow backup of entire clusters as >> well as role and tablespace definitions, we need to be able to get >> pg_dumpall to write it's output directly to a file in the same way, >> because we cannot redirect the child pg_dump IO streams (which also >> means we may miss errors, but I need to think about that some more). >> >> As far as I can see, adding a -f option to pg_dumpall should be straight >> forward, the only issue being that we'd need to pass pg_dump an >> additional (undocumented?) option to tell it to append to the output >> file instead of writing it as normal. >> >> Any thoughts or better ideas? >> > Use pgAdmin's "create script" funcion on the server. We said long ago we weren't going to replicate pg_dump functionality in pgAdmin - a brief discussion on the pgadmin-hackers list earlier indicates that people still feel the same way, and that time would be better spend fixing pg_dump/pg_dumpall. Regards, Dave.
Dave Page <dpage@postgresql.org> writes:
> As far as I can see, adding a -f option to pg_dumpall should be straight
> forward, the only issue being that we'd need to pass pg_dump an
> additional (undocumented?) option to tell it to append to the output
> file instead of writing it as normal.
Wouldn't it be easier/better to re-point stdout at the -f file, and not
touch pg_dump at all?
regards, tom lane
Dave Page <dpage@postgresql.org> writes:
> Hmm, well I have no interest in the latter at present, but assuming the
> powers that be will allow me some time to do so, I will look at merging
> pg_dump and pg_dumpall as that seems to be the way people want to go.
I think this will be an exercise in time-wasting, and very possibly
destabilize *both* tools. pg_dump has never been designed to reconnect
to a different database; for instance there isn't any code for resetting
all the internal state that it gathers. I think forking a separate
pg_dump for each database is a perfectly fine arrangement, and should be
left alone.
regards, tom lane
Tom Lane schrieb: > Dave Page <dpage@postgresql.org> writes: >> As far as I can see, adding a -f option to pg_dumpall should be straight >> forward, the only issue being that we'd need to pass pg_dump an >> additional (undocumented?) option to tell it to append to the output >> file instead of writing it as normal. > > Wouldn't it be easier/better to re-point stdout at the -f file, and not > touch pg_dump at all? Yeah, and maybe have a modifier like %n or something which would instead write different files and replaces %n with the name of the database... Regards Tino
Dave Page wrote: > In pgAdmin we use pg_dump's -f option to write backup files. The IO > streams are redirected to display status and errors etc. in the GUI. > > In order to enhance the interface to allow backup of entire clusters as > well as role and tablespace definitions, we need to be able to get > pg_dumpall to write it's output directly to a file in the same way, > because we cannot redirect the child pg_dump IO streams (which also > means we may miss errors, but I need to think about that some more). > > As far as I can see, adding a -f option to pg_dumpall should be straight > forward, the only issue being that we'd need to pass pg_dump an > additional (undocumented?) option to tell it to append to the output > file instead of writing it as normal. > > Any thoughts or better ideas? > Use pgAdmin's "create script" funcion on the server. Regards, Andreas
> ------- Original Message ------- > From: Tom Lane <tgl@sss.pgh.pa.us> > To: Dave Page <dpage@postgresql.org> > Sent: 1/5/07, 10:48:17 PM > Subject: Re: [HACKERS] -f <output file> option for pg_dumpall > > > Wouldn't it be easier/better to re-point stdout at the -f file, and not > touch pg_dump at all? First thing I tried, but using virtually identical code to that which we use with pg_dump it just hangs. The debugger tellsme there's a deadlock - my best guess is that stdin/out/err of the child shell & pg_dump processes don't get redirectedalong with their parents. I'm testing on Windows btw - dunno if *nix would be different. /D
> ------- Original Message ------- > From: Tom Lane <tgl@sss.pgh.pa.us> > To: Dave Page <dpage@postgresql.org> > Sent: 1/5/07, 10:52:37 PM > Subject: Re: [HACKERS] -f <output file> option for pg_dumpall > > I think this will be an exercise in time-wasting, and very possibly > destabilize *both* tools. pg_dump has never been designed to reconnect > to a different database; for instance there isn't any code for resetting > all the internal state that it gathers. I think forking a separate > pg_dump for each database is a perfectly fine arrangement, and should be > left alone. Hmm, would you be happy with my original proposal to add an append option to pg_dump? I'd also like to allow separate dumping of roles and tablespaces, and allow a default db to be specified instead of postgres/template1. /D
Dave Page wrote: > In pgAdmin we use pg_dump's -f option to write backup files. The IO > streams are redirected to display status and errors etc. in the GUI. > > In order to enhance the interface to allow backup of entire clusters > as well as role and tablespace definitions, we need to be able to get > pg_dumpall to write it's output directly to a file in the same way, > because we cannot redirect the child pg_dump IO streams (which also > means we may miss errors, but I need to think about that some more). I don't understand this. Errors are sent to stderr, and the real output is sent to stdout, where you can capture and save it. What is the problem? -- Peter Eisentraut http://developer.postgresql.org/~petere/
"Dave Page" <dpage@postgresql.org> writes:
>> From: Tom Lane <tgl@sss.pgh.pa.us>
>> I think forking a separate
>> pg_dump for each database is a perfectly fine arrangement, and should be
>> left alone.
> Hmm, would you be happy with my original proposal to add an append option to pg_dump?
I don't object to it in principle, but I think a bit more thought is
needed as to what's the goal. A stupid "append" option would be enough
for pg_dumpall's current capabilities (ie, text output only) --- but is
it reasonable to consider generalizing -Fc and -Ft modes to deal with
multiple databases, and if so how would that need to change pg_dump's
API? (I'm not at all sure this is feasible, but let's think about it
before plastering warts onto pg_dump, not after.)
> I'd also like to allow separate dumping of roles and tablespaces, and allow a default db to be specified instead of
postgres/template1.
Can't get excited about either, but no objection.
regards, tom lane
Peter Eisentraut wrote: > Dave Page wrote: >> In pgAdmin we use pg_dump's -f option to write backup files. The IO >> streams are redirected to display status and errors etc. in the GUI. >> >> In order to enhance the interface to allow backup of entire clusters >> as well as role and tablespace definitions, we need to be able to get >> pg_dumpall to write it's output directly to a file in the same way, >> because we cannot redirect the child pg_dump IO streams (which also >> means we may miss errors, but I need to think about that some more). > > I don't understand this. Errors are sent to stderr, and the real output > is sent to stdout, where you can capture and save it. What is the > problem? > On Windows at least, I cannot redirect stdout/stderr of child processes, only the parent (ie. pg_dumpall) that is executed by pgAdmin (the pg_dump processes just seem to hang, and the debugger reports a deadlock with no other useful info). I'm sure there is a way round this but a) it'll probably mean hacking wxWidgets or pg_dump about in ways I'm sure Vadim or Tom would dislike, and b) it would seem reasonable to offer similar functionality in pg_dumpall to that already in pg_dump anyway. Regards, Dave.
Tom Lane wrote: > "Dave Page" <dpage@postgresql.org> writes: >>> From: Tom Lane <tgl@sss.pgh.pa.us> >>> I think forking a separate >>> pg_dump for each database is a perfectly fine arrangement, and should be >>> left alone. > >> Hmm, would you be happy with my original proposal to add an append option to pg_dump? > > I don't object to it in principle, but I think a bit more thought is > needed as to what's the goal. A stupid "append" option would be enough > for pg_dumpall's current capabilities (ie, text output only) --- but is > it reasonable to consider generalizing -Fc and -Ft modes to deal with > multiple databases, and if so how would that need to change pg_dump's > API? (I'm not at all sure this is feasible, but let's think about it > before plastering warts onto pg_dump, not after.) Hmm, OK. I'll need to have a good look at the code before I can even think about commenting on that, which will have to wait until after I've finished bundling releases. Regards, Dave
Dave Page wrote: >> I don't object to it in principle, but I think a bit more thought is >> needed as to what's the goal. A stupid "append" option would be enough >> for pg_dumpall's current capabilities (ie, text output only) --- but is >> it reasonable to consider generalizing -Fc and -Ft modes to deal with >> multiple databases, and if so how would that need to change pg_dump's >> API? (I'm not at all sure this is feasible, but let's think about it >> before plastering warts onto pg_dump, not after.) > > Hmm, OK. I'll need to have a good look at the code before I can even > think about commenting on that, which will have to wait until after I've > finished bundling releases. And having done so, I agree that it's not really feasible without significant effort to allow each archive format to be closed and re-opened between multiple instances of pg_dump and pg_dumpall, as well as to allow them to support multiple databases and global objects (though they can effectively live in the default DB of course) within a single archive. I'm fairly certain it would be easier to merge the two programs as originally suggested, though that does indeed look trickier (and more dangerous) than I originally envisaged. How about adding the append option, but leaving it undocumented. That way if anyone gets the itch to do a full rewrite in the future we haven't necessarily got to continue to support an option we no longer want? Regards, Dave.
On Fri, Jan 05, 2007 at 08:05:26PM +0000, Dave Page wrote: > Andreas Pflug wrote: > >Dave Page wrote: > >>In pgAdmin we use pg_dump's -f option to write backup files. The IO > >>streams are redirected to display status and errors etc. in the GUI. > >> > >>In order to enhance the interface to allow backup of entire clusters as > >>well as role and tablespace definitions, we need to be able to get > >>pg_dumpall to write it's output directly to a file in the same way, > >>because we cannot redirect the child pg_dump IO streams (which also > >>means we may miss errors, but I need to think about that some more). > >> > >>As far as I can see, adding a -f option to pg_dumpall should be straight > >>forward, the only issue being that we'd need to pass pg_dump an > >>additional (undocumented?) option to tell it to append to the output > >>file instead of writing it as normal. > >> > >>Any thoughts or better ideas? > >> > >Use pgAdmin's "create script" funcion on the server. > > We said long ago we weren't going to replicate pg_dump functionality in > pgAdmin - a brief discussion on the pgadmin-hackers list earlier > indicates that people still feel the same way, and that time would be > better spend fixing pg_dump/pg_dumpall. It might make sense to provide a programmatic interface to pg_dump to provide tools like pgAdmin more flexibility. But it certainly doesn't make sense to re-create the dumping logic. In terms of integrating pg_dumpall and pg_dump; I don't really care if that happens, but I would like to see pg_dumpall supporting all the options that pg_dump does (a quick diff shows that pg_dumpall is currently missing support for -f, -F, -v, -Z, -C (which may or may not make sense), -E, -n & -t (might not make sense), -U and -W (probably OK). -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Jim C. Nasby wrote: > > > It might make sense to provide a programmatic interface to pg_dump to > provide tools like pgAdmin more flexibility. Are you talking about "pg_dump in a lib"? Certainly a good idea, because it allows better integration (e.g. progress bar). > But it certainly doesn't make sense to re-create the dumping logic. > > In terms of integrating pg_dumpall and pg_dump; I don't really care if > that happens, I can't make too much sense of integrating pg_dumpall anywhere. Dumping a whole cluster is certainly much of a planned job, not an interactive online one, because its output usually won't be usable except for disaster recovery. Not much function to "re-create" here, single exception is extracting cluster wide data, the -g option, that's why I mentioned scripting. But apparently this didn't get into pgadmin svn any more, so I need to retract this proposal. Regards, Andreas
Andreas Pflug wrote: > Not much function to "re-create" here, single > exception is extracting cluster wide data, the -g option, that's why I > mentioned scripting. But apparently this didn't get into pgadmin svn any > more, so I need to retract this proposal. Eh? Your SCRIPT code is still there - or do you mean something else? Regards, Dave.
Dave Page wrote: > Andreas Pflug wrote: > >> Not much function to "re-create" here, single >> exception is extracting cluster wide data, the -g option, that's why I >> mentioned scripting. But apparently this didn't get into pgadmin svn any >> more, so I need to retract this proposal. >> > > Eh? Your SCRIPT code is still there - or do you mean something else? > No GetScript implementation for pgServer. Regards, Andreas
Is there a TODO here? --------------------------------------------------------------------------- Dave Page wrote: > Dave Page wrote: > >> I don't object to it in principle, but I think a bit more thought is > >> needed as to what's the goal. A stupid "append" option would be enough > >> for pg_dumpall's current capabilities (ie, text output only) --- but is > >> it reasonable to consider generalizing -Fc and -Ft modes to deal with > >> multiple databases, and if so how would that need to change pg_dump's > >> API? (I'm not at all sure this is feasible, but let's think about it > >> before plastering warts onto pg_dump, not after.) > > > > Hmm, OK. I'll need to have a good look at the code before I can even > > think about commenting on that, which will have to wait until after I've > > finished bundling releases. > > And having done so, I agree that it's not really feasible without > significant effort to allow each archive format to be closed and > re-opened between multiple instances of pg_dump and pg_dumpall, as well > as to allow them to support multiple databases and global objects > (though they can effectively live in the default DB of course) within a > single archive. I'm fairly certain it would be easier to merge the two > programs as originally suggested, though that does indeed look trickier > (and more dangerous) than I originally envisaged. > > How about adding the append option, but leaving it undocumented. That > way if anyone gets the itch to do a full rewrite in the future we > haven't necessarily got to continue to support an option we no longer want? > > Regards, Dave. > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Possibly, to merge the two programs. I'm intending to put some time into the append and seperating globals items, but I don't think I have the time to merge the apps given Tom's concerns and some further investigation. Regards, Dave. Bruce Momjian wrote: > Is there a TODO here? > > --------------------------------------------------------------------------- > > Dave Page wrote: >> Dave Page wrote: >>>> I don't object to it in principle, but I think a bit more thought is >>>> needed as to what's the goal. A stupid "append" option would be enough >>>> for pg_dumpall's current capabilities (ie, text output only) --- but is >>>> it reasonable to consider generalizing -Fc and -Ft modes to deal with >>>> multiple databases, and if so how would that need to change pg_dump's >>>> API? (I'm not at all sure this is feasible, but let's think about it >>>> before plastering warts onto pg_dump, not after.) >>> Hmm, OK. I'll need to have a good look at the code before I can even >>> think about commenting on that, which will have to wait until after I've >>> finished bundling releases. >> And having done so, I agree that it's not really feasible without >> significant effort to allow each archive format to be closed and >> re-opened between multiple instances of pg_dump and pg_dumpall, as well >> as to allow them to support multiple databases and global objects >> (though they can effectively live in the default DB of course) within a >> single archive. I'm fairly certain it would be easier to merge the two >> programs as originally suggested, though that does indeed look trickier >> (and more dangerous) than I originally envisaged. >> >> How about adding the append option, but leaving it undocumented. That >> way if anyone gets the itch to do a full rewrite in the future we >> haven't necessarily got to continue to support an option we no longer want? >> >> Regards, Dave. >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 7: You can help support the PostgreSQL project by donating at >> >> http://www.postgresql.org/about/donate >
Dave Page wrote: > Possibly, to merge the two programs. I'm intending to put some time into > the append and seperating globals items, but I don't think I have the > time to merge the apps given Tom's concerns and some further investigation. Yes, I was just wondering if an append mode for Win32 would be an easy solution and put on the TODO list. I don't see a merge of the tools as being a win myself. --------------------------------------------------------------------------- > > Regards, Dave. > > Bruce Momjian wrote: > > Is there a TODO here? > > > > --------------------------------------------------------------------------- > > > > Dave Page wrote: > >> Dave Page wrote: > >>>> I don't object to it in principle, but I think a bit more thought is > >>>> needed as to what's the goal. A stupid "append" option would be enough > >>>> for pg_dumpall's current capabilities (ie, text output only) --- but is > >>>> it reasonable to consider generalizing -Fc and -Ft modes to deal with > >>>> multiple databases, and if so how would that need to change pg_dump's > >>>> API? (I'm not at all sure this is feasible, but let's think about it > >>>> before plastering warts onto pg_dump, not after.) > >>> Hmm, OK. I'll need to have a good look at the code before I can even > >>> think about commenting on that, which will have to wait until after I've > >>> finished bundling releases. > >> And having done so, I agree that it's not really feasible without > >> significant effort to allow each archive format to be closed and > >> re-opened between multiple instances of pg_dump and pg_dumpall, as well > >> as to allow them to support multiple databases and global objects > >> (though they can effectively live in the default DB of course) within a > >> single archive. I'm fairly certain it would be easier to merge the two > >> programs as originally suggested, though that does indeed look trickier > >> (and more dangerous) than I originally envisaged. > >> > >> How about adding the append option, but leaving it undocumented. That > >> way if anyone gets the itch to do a full rewrite in the future we > >> haven't necessarily got to continue to support an option we no longer want? > >> > >> Regards, Dave. > >> > >> > >> ---------------------------(end of broadcast)--------------------------- > >> TIP 7: You can help support the PostgreSQL project by donating at > >> > >> http://www.postgresql.org/about/donate > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Fri, 2007-01-05 at 17:52 -0500, Tom Lane wrote: > I think this will be an exercise in time-wasting, and very possibly > destabilize *both* tools. pg_dump has never been designed to reconnect > to a different database; for instance there isn't any code for resetting > all the internal state that it gathers. That is merely an implementation issue. The question of whether pg_dump and pg_dumpall should be separate programs is a question of design, IMHO. I don't think they need to be integrated any time soon, but if we were to design pg_dump and pg_dumpall from scratch, it seems more logical to use a single program, and therefore that is the long-term direction I think we should head in. -Neil
On Thu, 2007-01-11 at 14:36 -0500, Neil Conway wrote: > I don't think they need to be integrated any time soon, but if we were > to design pg_dump and pg_dumpall from scratch, it seems more logical to > use a single program On thinking about this some more, it might be useful to factor much of pg_dump's logic for reconstructing the state of a database into a shared library. This would make it relatively easy for developers to plug new archive formats into the library (in addition to the present 3 archive formats), or to make use of this functionality in other applications that want to reconstruct the logical state of a database from the content of the system catalogs. We could then provide a client app implemented on top of the library that would provide similar functionality to pg_dump. Moving pg_dump's functionality into the backend has been suggested in the past (and rejected for good reason), but I think this might be a more practical method for making the pg_dump logic more easily reusable. (While we're on the subject, this would also present a good opportunity to make pg_dump's command-line interface a little more sane. I wonder if pg_dump's syntax has gotten sufficiently complicated that some users might prefer to specify behavior via a configuration file, rather than a long string of command-line options.) -Neil
Neil Conway wrote: > On Thu, 2007-01-11 at 14:36 -0500, Neil Conway wrote: > >> I don't think they need to be integrated any time soon, but if we were >> to design pg_dump and pg_dumpall from scratch, it seems more logical to >> use a single program >> > > On thinking about this some more, it might be useful to factor much of > pg_dump's logic for reconstructing the state of a database into a shared > library. This would make it relatively easy for developers to plug new > archive formats into the library (in addition to the present 3 archive > formats), or to make use of this functionality in other applications > that want to reconstruct the logical state of a database from the > content of the system catalogs. We could then provide a client app > implemented on top of the library that would provide similar > functionality to pg_dump. > > Moving pg_dump's functionality into the backend has been suggested in > the past (and rejected for good reason), but I think this might be a > more practical method for making the pg_dump logic more easily reusable. > > > I like this idea. For example, we might usefully map some of this to psql \ commands, without having to replicate the underlying logic. cheers andrew
On Mon, Jan 15, 2007 at 10:13:16AM -0500, Andrew Dunstan wrote: > > > Neil Conway wrote: > >On Thu, 2007-01-11 at 14:36 -0500, Neil Conway wrote: > > > >>I don't think they need to be integrated any time soon, but if we were > >>to design pg_dump and pg_dumpall from scratch, it seems more logical to > >>use a single program > >> > > > >On thinking about this some more, it might be useful to factor much of > >pg_dump's logic for reconstructing the state of a database into a shared > >library. This would make it relatively easy for developers to plug new > >archive formats into the library (in addition to the present 3 archive > >formats), or to make use of this functionality in other applications > >that want to reconstruct the logical state of a database from the > >content of the system catalogs. We could then provide a client app > >implemented on top of the library that would provide similar > >functionality to pg_dump. > > > >Moving pg_dump's functionality into the backend has been suggested in > >the past (and rejected for good reason), but I think this might be a > >more practical method for making the pg_dump logic more easily reusable. > > > > > > > > I like this idea. For example, we might usefully map some of this to > psql \ commands, without having to replicate the underlying logic. Don't we already do this with the .psqlrc file? --elein
elein wrote: > On Mon, Jan 15, 2007 at 10:13:16AM -0500, Andrew Dunstan wrote: >> >> >> Neil Conway wrote: >> >On Thu, 2007-01-11 at 14:36 -0500, Neil Conway wrote: >> > >> >>I don't think they need to be integrated any time soon, but if we were >> >>to design pg_dump and pg_dumpall from scratch, it seems more logical >> to >> >>use a single program >> >> >> > >> >On thinking about this some more, it might be useful to factor much of >> >pg_dump's logic for reconstructing the state of a database into a >> shared >> >library. This would make it relatively easy for developers to plug new >> >archive formats into the library (in addition to the present 3 archive >> >formats), or to make use of this functionality in other applications >> >that want to reconstruct the logical state of a database from the >> >content of the system catalogs. We could then provide a client app >> >implemented on top of the library that would provide similar >> >functionality to pg_dump. >> > >> >Moving pg_dump's functionality into the backend has been suggested in >> >the past (and rejected for good reason), but I think this might be a >> >more practical method for making the pg_dump logic more easily >> reusable. >> > >> > >> > >> >> I like this idea. For example, we might usefully map some of this to >> psql \ commands, without having to replicate the underlying logic. > > Don't we already do this with the .psqlrc file? > No. \ commands are implemented in C code. cheers andrew