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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #4817: Dump of 8.3 hstore not restorable to 8.4 (RECHECK)
Дата
Msg-id 17969.1243368783@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #4817: Dump of 8.3 hstore not restorable to 8.4 (RECHECK)  (David Blewett <david@dawninglight.net>)
Ответы Re: BUG #4817: Dump of 8.3 hstore not restorable to 8.4 (RECHECK)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #4817: Dump of 8.3 hstore not restorable to 8.4 (RECHECK)