Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group