Re: BUG #4817: Dump of 8.3 hstore not restorable to 8.4 (RECHECK) - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #4817: Dump of 8.3 hstore not restorable to 8.4 (RECHECK)
Date
Msg-id 17969.1243368783@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #4817: Dump of 8.3 hstore not restorable to 8.4 (RECHECK)  (David Blewett <david@dawninglight.net>)
Responses Re: BUG #4817: Dump of 8.3 hstore not restorable to 8.4 (RECHECK)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
David Blewett <david@dawninglight.net> writes:
> It looks like this relates back to the "Remove lossy-operator RECHECK flag?"
> discussion [1] 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
>> bet.

> 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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal
Next
From: Tom Lane
Date:
Subject: Re: BUG #4817: Dump of 8.3 hstore not restorable to 8.4 (RECHECK)