From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com> |
Subject: | Re: {**Spam**} Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable |
Date: | 2008-01-31 15:25:54 |
Message-ID: | 7952.1201793154@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> Le jeudi 31 janvier 2008, Tom Lane a crit:
>> We have *never* promised that pg_dump version N could dump from server
>> version N+1 .., in fact, personally I'd like to make that case be a hard
>> error, rather than something people could override with -i.
> Are you thinking about next major or minor version ? All the same?
> Is there some real good reason not to dump say 8.2.6 server with the pg_dump
> from an 8.2.5 installation?
I'm thinking next major. In principle there could be cases where a
minor update could break pg_dump, but it seems unlikely enough that
it's not reasonable to embed such a policy in the code. As for
next major, though, the mere existence of the -i switch is a foot-gun
with no significant value.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-01-31 15:28:18 | Re: Oops - BF:Mastodon just died |
Previous Message | Andrew Dunstan | 2008-01-31 15:21:09 | Re: Oops - BF:Mastodon just died |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-01-31 15:28:59 | Re: Remove pg_dump -i option (was Re: Proposed patch: synchronized_scanning GUC variable) |
Previous Message | Bruce Momjian | 2008-01-31 15:14:58 | Re: Remove pg_dump -i option (was Re: Proposed patch: synchronized_scanning GUC variable) |