Magnus Hagander <mag...@hagander.net> writes: > On Wed, May 7, 2014 at 2:56 PM, Andres Freund <and...@2ndquadrant.com>wrote: >> Well, I guess it depends on what we define 'beta1' to be. Imo evaluating >> problematic pieces of new code, locating unfinished pieces is part of >> that. I don't see much point in forbidding incompatible changes in beta1 >> personally. That robs th the development cycle of the only period where >> users can actually test the new version in a halfway sane manner and >> report back with things that apparently broken.
> We need to be very careful to tell people about it though. Preferrably if > we *know* a dump/reload will be needed to go beta1->beta2, we should > actually document that in the releasenotes of beta1 already. So people can > make proper plans.. This seems like much ado about very little. The policy will be the same as it ever was: once beta1 is out, we prefer to avoid forcing an initdb, but we'll do it if we have to. In any case, +1 for fixing whatever needs to be fixed now; I expect to have a fix for the limited-GIN-index-length issue later today, and that really is also an on-disk format change, though it won't affect short index entries. ("Short" is TBD; I was thinking of hashing keys longer than say 128 bytes.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers