From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Joel Jacobson <joel(at)trustly(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [BUG FIX] Version number expressed in octal form by mistake |
Date: | 2013-12-29 00:41:49 |
Message-ID: | 28881.1388277709@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> Oh, I just noticed that this is for the *pg_restore* code, not the
> pg_dump code, so there isn't necessarily a conflict with the docs.
> The pg_dump code does match the docs on its version check. The
> question becomes, for each supported version, what do we want to
> set into AHX->minRemoteVersion before opening the connection to the
> target database? Do we really want a 9.4 executable to be
> attempting to restore to a 7.1 database cluster? What about
> backpatching?
On reflection, I'm not sure that pg_restore as such should be applying any
server version check at all. pg_restore itself has precious little to do
with whether there will be a compatibility problem; that's mostly down to
the DDL that pg_dump put into the archive file. And we don't have enough
information to be very sure about whether it will work, short of actually
trying it. So why should the code arbitrarily refuse to try?
So I'm inclined to propose that we set min/max to 0 and 999999 here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-12-29 01:08:30 | Re: truncating pg_multixact/members |
Previous Message | Tom Lane | 2013-12-28 22:16:01 | Re: planner missing a trick for foreign tables w/OR conditions |