Re: [PATCH] 8.5 TODO: Add comments to output indicating version of pg_dump and of the database server

From pg_dump/pg_restore section (9.2 of the Todo page on the
PostgreSQL Wiki), is the following item
"Add comments to output indicating version of pg_dump and of the
database server"

simply asking for a change to the pg_dump header from:

--
-- PostgreSQL database dump
--

to something like:

-- PostgreSQL database dump
--
-- pg_dump version: 8.5devel
--
-- remote database version: 8.5devel (80500)
--

?

"shakahshakah(at)gmail(dot)com" <shakahshakah(at)gmail(dot)com> writes:
> From pg_dump/pg_restore section (9.2 of the Todo page on the
> PostgreSQL Wiki), is the following item
> "Add comments to output indicating version of pg_dump and of the
> database server"
> simply asking for a change to the pg_dump header from:

I think so, but what's not clear is whether this is a good idea to do
in the default output. It might only be appropriate in "verbose" mode,
so as not to introduce unnecessary diffs between logically identical
dumps. We long ago got rid of timestamps in the default output for
exactly that reason.

Another issue is that it's not all that clear what to do or how to do it
for archive dumps --- do you then want both pg_dump and pg_restore to
tell you about themselves? If pg_restore adds anything, then this'd
also break the principle that pg_dump >foo should give identical output
to pg_dump -Fc | pg_restore >foo. Which is something that I for one
put a great deal of stock in, for testing purposes.

regards, tom lane

On Fri, 2009-09-25 at 16:59 -0400, Tom Lane wrote:
> "shakahshakah(at)gmail(dot)com" <shakahshakah(at)gmail(dot)com> writes:
> > From pg_dump/pg_restore section (9.2 of the Todo page on the
> > PostgreSQL Wiki), is the following item
> > "Add comments to output indicating version of pg_dump and of the
> > database server"
> > simply asking for a change to the pg_dump header from:
>
> I think so, but what's not clear is whether this is a good idea to do
> in the default output. It might only be appropriate in "verbose" mode,
> so as not to introduce unnecessary diffs between logically identical
> dumps.

Well, a diff of the same database made by different (major) versions of
pg_dump will already be different in most situations, so adding the
pg_dump version number in it is essentially free from this perspective.

What is the use case for adding the server version?

I can imagine something like wanting to know exactly where the dump came
from, but then host name and such would be better. (And then you can
infer the server version from that.)

> Another issue is that it's not all that clear what to do or how to do it
> for archive dumps --- do you then want both pg_dump and pg_restore to
> tell you about themselves?

I don't see a good reason for pg_restore to get involved.

On Sat, Sep 26, 2009 at 11:02:55PM +0300, Peter Eisentraut wrote:
> On Fri, 2009-09-25 at 16:59 -0400, Tom Lane wrote:
> > "shakahshakah(at)gmail(dot)com" <shakahshakah(at)gmail(dot)com> writes:
> > > From pg_dump/pg_restore section (9.2 of the Todo page on the
> > > PostgreSQL Wiki), is the following item "Add comments to output
> > > indicating version of pg_dump and of the database server" simply
> > > asking for a change to the pg_dump header from:
> >
> > I think so, but what's not clear is whether this is a good idea to
> > do in the default output. It might only be appropriate in
> > "verbose" mode, so as not to introduce unnecessary diffs between
> > logically identical dumps.
>
> Well, a diff of the same database made by different (major) versions
> of pg_dump will already be different in most situations, so adding
> the pg_dump version number in it is essentially free from this
> perspective.
>
> What is the use case for adding the server version?

There have been cases where pg_restore doesn't fix infelicities. For
example, there was a time when it was a good idea to run adddepend
after the reload. Knowing what server version the dump came from
could be handy for this kind of case.

> I can imagine something like wanting to know exactly where the dump
> came from, but then host name and such would be better. (And then
> you can infer the server version from that.)

You can infer the server version until the next upgrade, at which
point the information is lost.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Sat, Sep 26, 2009 at 6:48 PM, David Fetter <david(at)fetter(dot)org> wrote:
> On Sat, Sep 26, 2009 at 11:02:55PM +0300, Peter Eisentraut wrote:
>> On Fri, 2009-09-25 at 16:59 -0400, Tom Lane wrote:
>> > "shakahshakah(at)gmail(dot)com" <shakahshakah(at)gmail(dot)com> writes:
>> > > From pg_dump/pg_restore section (9.2 of the Todo page on the
>> > > PostgreSQL Wiki), is the following item "Add comments to output
>> > > indicating version of pg_dump and of the database server" simply
>> > > asking for a change to the pg_dump header from:
>> >
>> > I think so, but what's not clear is whether this is a good idea to
>> > do in the default output.  It might only be appropriate in
>> > "verbose" mode, so as not to introduce unnecessary diffs between
>> > logically identical dumps.
>>
>> Well, a diff of the same database made by different (major) versions
>> of pg_dump will already be different in most situations, so adding
>> the pg_dump version number in it is essentially free from this
>> perspective.
>>
>> What is the use case for adding the server version?
>
> There have been cases where pg_restore doesn't fix infelicities.  For
> example, there was a time when it was a good idea to run adddepend
> after the reload.  Knowing what server version the dump came from
> could be handy for this kind of case.
>
>> I can imagine something like wanting to know exactly where the dump
>> came from, but then host name and such would be better.  (And then
>> you can infer the server version from that.)
>
> You can infer the server version until the next upgrade, at which
> point the information is lost.
>
> Cheers,
> David.

Attached s/b a patch for the 8.5 TODO "Add comments to output indicating version
of pg_dump and of the database server" (pg_dump/pg_restore section, 9.2).

In verbose mode, pg_dump version and remote database version now appear
in the "plain" output format.

For example, original verbose output:
--
-- PostgreSQL database dump
--

-- Started on 2009-09-27 11:05:52 UTC

SET statement_timeout = 0;
[...etc...]

New verbose output:
--
-- PostgreSQL database dump
--

--
-- pg_dump version: 8.5devel
--
-- remote database version: 8.1.3 (80103)
--

-- Started on 2009-09-27 11:05:52 UTC

SET statement_timeout = 0;
[...etc...]

peter_e(at)gmx(dot)net (Peter Eisentraut) writes:
> On Fri, 2009-09-25 at 16:59 -0400, Tom Lane wrote:
>> "shakahshakah(at)gmail(dot)com" <shakahshakah(at)gmail(dot)com> writes:
>> > From pg_dump/pg_restore section (9.2 of the Todo page on the
>> > PostgreSQL Wiki), is the following item
>> > "Add comments to output indicating version of pg_dump and of the
>> > database server"
>> > simply asking for a change to the pg_dump header from:
>>
>> I think so, but what's not clear is whether this is a good idea to do
>> in the default output. It might only be appropriate in "verbose" mode,
>> so as not to introduce unnecessary diffs between logically identical
>> dumps.
>
> Well, a diff of the same database made by different (major) versions of
> pg_dump will already be different in most situations, so adding the
> pg_dump version number in it is essentially free from this perspective.
>
> What is the use case for adding the server version?
>
> I can imagine something like wanting to know exactly where the dump came
> from, but then host name and such would be better. (And then you can
> infer the server version from that.)

I added this ToDo because we had a case where we were spelunking
through some old pg_dumps, and the provenance was sufficiently distant
that we couldn't readily infer what PostgreSQL version was involved.

If pg_dump reported something like:

-- pg_dump version: 8.5_devel
-- postgres server version: 8.4.17

then it would be trivial to ascertain the information.

Actually, I have no argument with your point; perhaps a whole "header
section" is the right answer:

-- pg_dump version: 8.5_devel
-- postgres server version: 8.4.17
-- dump began at: 2010-07-01 14:22:27 EDT
-- server name: wolfe
-- more, maybe?

>> Another issue is that it's not all that clear what to do or how to do it
>> for archive dumps --- do you then want both pg_dump and pg_restore to
>> tell you about themselves?
>
> I don't see a good reason for pg_restore to get involved.

Agreed. This isn't needed for pg_restore to do anything better; it's
so that humans can do better "archaeology."
--
let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;;
http://linuxfinances.info/info/languages.html
Rules of the Evil Overlord #187. "I will not hold lavish banquets in
the middle of a famine. The good PR among the guests doesn't make up
for the bad PR among the masses." <http://www.eviloverlord.com/>

Jim Cox escribió:

> Attached s/b a patch for the 8.5 TODO "Add comments to output indicating version
> of pg_dump and of the database server" (pg_dump/pg_restore section, 9.2).

Hmm, what happens if you do a pg_dump -Fc? Is this info saved anywhere
in the dump? Surely if thi is useful in the text dump, it is useful in
the binary format dumps too.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On Tue, Sep 29, 2009 at 12:00 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Jim Cox escribió:
>
>> Attached s/b a patch for the 8.5 TODO "Add comments to output indicating version
>> of pg_dump and of the database server" (pg_dump/pg_restore section, 9.2).
>
> Hmm, what happens if you do a pg_dump -Fc?  Is this info saved anywhere
> in the dump?  Surely if thi is useful in the text dump, it is useful in
> the binary format dumps too.

(forgot to reply all)

pg_restore's "-l, --list print summarized TOC of the archive" option
does display the information in custom format dumps, e.g.:

prompt$ /usr/local/pgsql/bin/pg_restore -l < /tmp/mytest.dump
;
; Archive created at Tue Sep 29 13:48:37 2009
; dbname: mytest
; TOC Entries: 9
; Compression: -1
; Dump Version: 1.11-0
; Format: CUSTOM
; Integer: 4 bytes
; Offset: 8 bytes
; Dumped from database version: 8.4.0
; Dumped by pg_dump version: 8.4.0

Jim Cox wrote:
> On Tue, Sep 29, 2009 at 12:00 AM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
> > Jim Cox escribi?:
> >
> >> Attached s/b a patch for the 8.5 TODO "Add comments to output indicating version
> >> of pg_dump and of the database server" (pg_dump/pg_restore section, 9.2).
> >
> > Hmm, what happens if you do a pg_dump -Fc? ?Is this info saved anywhere
> > in the dump? ?Surely if thi is useful in the text dump, it is useful in
> > the binary format dumps too.
>
> (forgot to reply all)
>
> pg_restore's "-l, --list print summarized TOC of the archive" option
> does display the information in custom format dumps, e.g.:
>
> prompt$ /usr/local/pgsql/bin/pg_restore -l < /tmp/mytest.dump
> ;
> ; Archive created at Tue Sep 29 13:48:37 2009
> ; dbname: mytest
> ; TOC Entries: 9
> ; Compression: -1
> ; Dump Version: 1.11-0
> ; Format: CUSTOM
> ; Integer: 4 bytes
> ; Offset: 8 bytes
> ; Dumped from database version: 8.4.0
> ; Dumped by pg_dump version: 8.4.0

Are we sure we don't want a date/time in the ASCII dump? It would
affect database diffs, but I can see it useful too.

--
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. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Are we sure we don't want a date/time in the ASCII dump? It would
> affect database diffs, but I can see it useful too.

We used to have one, and it was removed by popular demand
(or actually demoted to be printed only in verbose mode, IIRC).
I don't feel a need to revisit that decision.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Are we sure we don't want a date/time in the ASCII dump? It would
> > affect database diffs, but I can see it useful too.
>
> We used to have one, and it was removed by popular demand
> (or actually demoted to be printed only in verbose mode, IIRC).
> I don't feel a need to revisit that decision.

OK, thanks, I had forgotten.

--
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. +

On Fri, Oct 2, 2009 at 6:11 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> > Are we sure we don't want a date/time in the ASCII dump?  It would
>> > affect database diffs, but I can see it useful too.
>>
>> We used to have one, and it was removed by popular demand
>> (or actually demoted to be printed only in verbose mode, IIRC).
>> I don't feel a need to revisit that decision.
>
> OK, thanks, I had forgotten.
>

To Tom's point, the patch only outputs the new info in verbose mode,
and in that mode a timestamp is indeed already output (it is the
subsequent line in the ASCII dump, actually).

Jim Cox wrote:
> On Fri, Oct 2, 2009 at 6:11 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Tom Lane wrote:
> >> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> >> > Are we sure we don't want a date/time in the ASCII dump? ?It would
> >> > affect database diffs, but I can see it useful too.
> >>
> >> We used to have one, and it was removed by popular demand
> >> (or actually demoted to be printed only in verbose mode, IIRC).
> >> I don't feel a need to revisit that decision.
> >
> > OK, thanks, I had forgotten.
> >
>
> To Tom's point, the patch only outputs the new info in verbose mode,
> and in that mode a timestamp is indeed already output (it is the
> subsequent line in the ASCII dump, actually).

Thank you.

--
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. +

shakahshakah(at)gmail(dot)com wrote:
> -- PostgreSQL database dump
> --
> -- pg_dump version: 8.5devel
> --
> -- remote database version: 8.5devel (80500)
> --
>

FWIW, and I havent read the entire thread, but pg_dump already *stores*
this information in a custom format. Try:

pg_dump -Fc blah
pg_restore -L ...

and you will get something like:

;
; Archive created at Sun Nov 29 12:34:24 2009
; dbname: blah
; TOC Entries: 202
; Compression: -1
; Dump Version: 1.10-0
; Format: CUSTOM
; Integer: 4 bytes
; Offset: 8 bytes
; Dumped from database version: 8.0.3
; Dumped by pg_dump version: 8.0.3
;

so, all that is needed is to add the relevant statements into the output
code.

What happened to this patch? I don't see any objections, but it was not
applied.

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

Jim Cox wrote:
> On Tue, Sep 29, 2009 at 12:00 AM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
> > Jim Cox escribi?:
> >
> >> Attached s/b a patch for the 8.5 TODO "Add comments to output indicating version
> >> of pg_dump and of the database server" (pg_dump/pg_restore section, 9.2).
> >
> > Hmm, what happens if you do a pg_dump -Fc? ?Is this info saved anywhere
> > in the dump? ?Surely if thi is useful in the text dump, it is useful in
> > the binary format dumps too.
>
> (forgot to reply all)
>
> pg_restore's "-l, --list print summarized TOC of the archive" option
> does display the information in custom format dumps, e.g.:
>
> prompt$ /usr/local/pgsql/bin/pg_restore -l < /tmp/mytest.dump
> ;
> ; Archive created at Tue Sep 29 13:48:37 2009
> ; dbname: mytest
> ; TOC Entries: 9
> ; Compression: -1
> ; Dump Version: 1.11-0
> ; Format: CUSTOM
> ; Integer: 4 bytes
> ; Offset: 8 bytes
> ; Dumped from database version: 8.4.0
> ; Dumped by pg_dump version: 8.4.0
>
> --
> 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
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +

On Mon, Feb 22, 2010 at 8:55 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> What happened to this patch? I don't see any objections, but it was not
> applied.

I think that the patch author never added it to the open CommitFest
and nobody else thought it was important enough to pick up. It looks
innocuous to me; want to go ahead and apply?

...Robert

On 2/23/10 10:14 AM, Robert Haas wrote:
> On Mon, Feb 22, 2010 at 8:55 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> What happened to this patch? I don't see any objections, but it was not
>> applied.
>
> I think that the patch author never added it to the open CommitFest
> and nobody else thought it was important enough to pick up. It looks
> innocuous to me; want to go ahead and apply?

I'd say yes. It's post-freeze, but this falls into the class of "oops,
we forgot about this patch" which the CFs were designed to prevent.

--Josh Berkus

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> On 2/23/10 10:14 AM, Robert Haas wrote:
>> On Mon, Feb 22, 2010 at 8:55 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>> What happened to this patch? I don't see any objections, but it was not
>>> applied.
>>
>> I think that the patch author never added it to the open CommitFest
>> and nobody else thought it was important enough to pick up. It looks
>> innocuous to me; want to go ahead and apply?

> I'd say yes. It's post-freeze, but this falls into the class of "oops,
> we forgot about this patch" which the CFs were designed to prevent.

That would be an argument for sticking this in the next CF, not for
applying it now --- it was submitted after the close of the last CF no?

regards, tom lane

Tom Lane escribió:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > On 2/23/10 10:14 AM, Robert Haas wrote:
> >> On Mon, Feb 22, 2010 at 8:55 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >>> What happened to this patch? I don't see any objections, but it was not
> >>> applied.
> >>
> >> I think that the patch author never added it to the open CommitFest
> >> and nobody else thought it was important enough to pick up. It looks
> >> innocuous to me; want to go ahead and apply?
>
> > I'd say yes. It's post-freeze, but this falls into the class of "oops,
> > we forgot about this patch" which the CFs were designed to prevent.
>
> That would be an argument for sticking this in the next CF, not for
> applying it now --- it was submitted after the close of the last CF no?

Sep. 29 2009?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane escribi:
>> That would be an argument for sticking this in the next CF, not for
>> applying it now --- it was submitted after the close of the last CF no?

> Sep. 29 2009?

Oh, I was thinking it had just come in recently, but looking back you're
right. It did slip through the cracks.

However, has the patch actually been reviewed? pg_dump is a piece of
code where it is notoriously easy for novices to do things wrong,
and this is especially true for adding output that should only come out
in particular cases.

regards, tom lane

On Tue, Feb 23, 2010 at 1:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Tom Lane escribió:
>>> That would be an argument for sticking this in the next CF, not for
>>> applying it now --- it was submitted after the close of the last CF no?
>
>> Sep. 29 2009?
>
> Oh, I was thinking it had just come in recently, but looking back you're
> right.  It did slip through the cracks.
>
> However, has the patch actually been reviewed?  pg_dump is a piece of
> code where it is notoriously easy for novices to do things wrong,
> and this is especially true for adding output that should only come out
> in particular cases.

It's a fairly trivial patch. I took a quick look at it. It needs
more than that, but I think not too much more. I think it would be
less effort for someone to review it and make a decision than it would
be to keep it as an open item for the next 6 months. But that's just
MHO: if the consensus is to postpone it, then let's just do that and
move on.

...Robert

Robert Haas wrote:
> On Tue, Feb 23, 2010 at 1:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> >> Tom Lane escribi?:
> >>> That would be an argument for sticking this in the next CF, not for
> >>> applying it now --- it was submitted after the close of the last CF no?
> >
> >> Sep. 29 2009?
> >
> > Oh, I was thinking it had just come in recently, but looking back you're
> > right. ?It did slip through the cracks.
> >
> > However, has the patch actually been reviewed? ?pg_dump is a piece of
> > code where it is notoriously easy for novices to do things wrong,
> > and this is especially true for adding output that should only come out
> > in particular cases.
>
> It's a fairly trivial patch. I took a quick look at it. It needs
> more than that, but I think not too much more. I think it would be
> less effort for someone to review it and make a decision than it would
> be to keep it as an open item for the next 6 months.

Agreed, applied, and TODO updated.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Feb 23, 2010 at 1:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> However, has the patch actually been reviewed? pg_dump is a piece of
>> code where it is notoriously easy for novices to do things wrong,
>> and this is especially true for adding output that should only come out
>> in particular cases.

> It's a fairly trivial patch. I took a quick look at it. It needs
> more than that, but I think not too much more. I think it would be
> less effort for someone to review it and make a decision than it would
> be to keep it as an open item for the next 6 months. But that's just
> MHO: if the consensus is to postpone it, then let's just do that and
> move on.

Well, "trivial" and "correct" are entirely different things :-(.
If we're still talking about
http://archives.postgresql.org/message-id/c2ee6dbd0909270432hd7773edk144080185fb5259d@mail.gmail.com
then it is in fact printing the wrong thing for pg_dump's version.
PG_VERSION is a compiled-in constant so what you will get when examining
an archive is pg_restore's version not pg_dump's version. This is
no doubt fixable but it looks like the code doesn't currently bother
to set archiveDumpVersion in the plain pg_dump code path, so it's
not entirely trivial.

regards, tom lane

Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Tue, Feb 23, 2010 at 1:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> However, has the patch actually been reviewed? pg_dump is a piece of
> >> code where it is notoriously easy for novices to do things wrong,
> >> and this is especially true for adding output that should only come out
> >> in particular cases.
>
> > It's a fairly trivial patch. I took a quick look at it. It needs
> > more than that, but I think not too much more. I think it would be
> > less effort for someone to review it and make a decision than it would
> > be to keep it as an open item for the next 6 months. But that's just
> > MHO: if the consensus is to postpone it, then let's just do that and
> > move on.
>
> Well, "trivial" and "correct" are entirely different things :-(.
> If we're still talking about
> http://archives.postgresql.org/message-id/c2ee6dbd0909270432hd7773edk144080185fb5259d@mail.gmail.com

Yes, that is the patch.

> then it is in fact printing the wrong thing for pg_dump's version.

Uh, right now it is printing:

-- pg_dump version: 9.0devel
--
-- remote database version: 9.0devel (90000)

That is in the SQL output file.

> PG_VERSION is a compiled-in constant so what you will get when examining
> an archive is pg_restore's version not pg_dump's version. This is
> no doubt fixable but it looks like the code doesn't currently bother
> to set archiveDumpVersion in the plain pg_dump code path, so it's
> not entirely trivial.

So you are saying if you run pg_restore on the SQL dump file, it doesn't
pick up the version? I didn't even know pg_restore could do that for
text dump files. In fact, I can't get it to work:

$ pg_dump -v test > /rtmp/x
...
$ pg_restore -l /rtmp/x -d test
pg_restore: [archiver] input file does not appear to be a valid archive

I obviously am missing something.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> Well, "trivial" and "correct" are entirely different things :-(.

> So you are saying if you run pg_restore on the SQL dump file, it doesn't
> pick up the version?

No, I'm saying it printed the wrong thing if you did pg_restore -v from
an archive file made by a different pg_dump version. I fixed it, but
this patch was *not* ready to commit.

regards, tom lane