David Blewett <david(at)dawninglight(dot)net> writes:
> It looks like this relates back to the "Remove lossy-operator RECHECK flag?"
> discussion  last April. That seemed to end with this decision:
>> For the moment I have it doing #1, but it strikes me that that is only
>> useful if 8.4 getsto release without having made any backwards-incompatible
>> changes in pg_dump output, which is probably not better than a fifty-fifty
> Has there been any backwards-incompatible changes since then?
Just to answer the question, I can't find any. There have been plenty
of feature additions, and if you dump from an 8.4 database that's using
any of those features then the dump wouldn't reload into 8.3. But using
current pg_dump to dump from an 8.3 database will produce a dump that
loads back into 8.3, AFAICS (and some simple testing with the regression
database supports that).
If we remove the RECHECK printout then this will stop being true ---
and worse, it will break silently and in a way that will only cause
you to get occasional wrong answers from your queries.
Even though we discourage people from using later pg_dumps to reload
into older servers, I'm not sure that I want us to loose that kind of
foot-gun on the world. So there's still no good answer here.
regards, tom lane
In response to
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2009-05-26 22:08:30|
|Subject: Re: BUG #4817: Dump of 8.3 hstore not restorable to 8.4 (RECHECK) |
|Previous:||From: Tom Lane||Date: 2009-05-26 18:35:54|
|Subject: Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal |