Re: rfc: add pg_dump options to dump output

I would like to add the flags given to pg_dump into the output of the pg_dump
file. For text dumps, the output would go on a line below the current header,
so output would look like:

--
-- PostgreSQL database dump complete
--
-- Generated by: pg_dump -s -U rob pagila
--

For compressed dumps, the output could go into the headers created with -l,
for example:

; Archive created at Mon Jun 2 16:43:19 2008
; dbname: pgods
; TOC Entries: 3
; Compression: -1
; Dump Version: 1.10-0
; Format: CUSTOM
; Integer: 4 bytes
; Offset: 8 bytes
; Dumped from database version: 8.3.1
; Dumped by pg_dump version: 8.3.1
; Generated by: pg_dump -s -U rob -Fc pagila
;
;
; Selected TOC Entries:

Anyone see any issues with this? Should there be other information taken into
account? Does this need to be an option itself, or can we just do it in all
cases?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Robert,

> Anyone see any issues with this? Should there be other information taken
> into account? Does this need to be an option itself, or can we just do
> it in all cases?

+1 to do it in all cases.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
> I would like to add the flags given to pg_dump into the output of the pg_dump
> file.

Why? What is the value of this added complication?

> Anyone see any issues with this?

I'm a bit worried about breaking diff-equality of matching dumps, but
mainly I don't see the point.

regards, tom lane

On Tue, Jun 03, 2008 at 01:17:43AM -0400, Tom Lane wrote:
> Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
> > I would like to add the flags given to pg_dump into the output of the pg_dump
> > file.

+1, FWIW

> > Anyone see any issues with this?
>
> I'm a bit worried about breaking diff-equality of matching dumps,

I don't tend to do this too often, but I'm curious if others make a habit of this
for some process. When I have done this, it's normally one-off case.

> but mainly I don't see the point.

It's informative, no? Sure if every dump used the same flags, it's pointless.
However, that's certainly not the case: --schema, --exclude-schema, etc. ie, I
imagine it would be nice to have the information about how a dump was performed
without having to track down someone's script or pester the person who's in the
know via e-mail if you wanted/needed to repeat the process.

On Tuesday 03 June 2008 01:17:43 Tom Lane wrote:
> Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
> > Anyone see any issues with this?
> I'm a bit worried about breaking diff-equality of matching dumps,

If you are calling pg_dump with different flags, it seems likely your breaking
diff equality anyway so I'm not sure how valid that is. Actually, in some
cases I'd expect the difference in flags might actually make other difference
more clear, for example comparing a dump with a -T flag vs. one without, the
differences might be scattered throughout the dump (table, triggers,indexes),
seeing the difference in the dump flags would likely make things more
concrete.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

James William Pye <pgsql(at)jwp(dot)name> writes:
> On Tue, Jun 03, 2008 at 01:17:43AM -0400, Tom Lane wrote:
>> but mainly I don't see the point.

> It's informative, no?

Well, the stuff included into the dump by pg_dump -v is informative,
too. But we stopped doing that by default because of complaints.
I remain unconvinced that this proposal won't suffer the same fate.

regards, tom lane

Robert Treat wrote:

> If you are calling pg_dump with different flags, it seems likely your breaking
> diff equality anyway so I'm not sure how valid that is.
What about different users? Different connection options will result in
the same file but it breaks diff-dump tools. I don't see the point of
adding such an option.

--
Euler Taveira de Oliveira
http://www.timbira.com/

On Mon, Jun 02, 2008 at 02:06:57PM -0700, Josh Berkus wrote:
> Robert,
>
> > Anyone see any issues with this? Should there be other information taken
> > into account? Does this need to be an option itself, or can we just do
> > it in all cases?
>
> +1 to do it in all cases.

+1. I've definitely been in situations where I had to try and track down
what options had been used originally.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

On Tue, 3 Jun 2008, Tom Lane wrote:

> Well, the stuff included into the dump by pg_dump -v is informative,
> too. But we stopped doing that by default because of complaints.
> I remain unconvinced that this proposal won't suffer the same fate.

I think it would be reasonable to only include the list of options used in
the dump if you use one that changes what appears in the dump. That way,
you wouldn't see anything by default. But if you make a modification that
will likely break a diff with an existing dump done with the default
parameters, the option change that introduced that should show at the very
beginning.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Is this a TODO item?

---------------------------------------------------------------------------

Greg Smith wrote:
> On Tue, 3 Jun 2008, Tom Lane wrote:
>
> > Well, the stuff included into the dump by pg_dump -v is informative,
> > too. But we stopped doing that by default because of complaints.
> > I remain unconvinced that this proposal won't suffer the same fate.
>
> I think it would be reasonable to only include the list of options used in
> the dump if you use one that changes what appears in the dump. That way,
> you wouldn't see anything by default. But if you make a modification that
> will likely break a diff with an existing dump done with the default
> parameters, the option change that introduced that should show at the very
> beginning.
>
> --
> * Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +