Re: BUG #4817: Dump of 8.3 hstore not restorable to 8.4 (RECHECK)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Blewett <david(at)dawninglight(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4817: Dump of 8.3 hstore not restorable to 8.4 (RECHECK)
Date: 2009-05-26 20:13:03
Message-ID: 17969.1243368783@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

David Blewett <david(at)dawninglight(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2009-05-26 22:08:30 Re: BUG #4817: Dump of 8.3 hstore not restorable to 8.4 (RECHECK)
Previous Message Tom Lane 2009-05-26 18:35:54 Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal