On Tue, May 5, 2015 at 10:20 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > (I think it is possible that the behavior change is actually problematic > > as opposed to just behaving differently. For instance, if the function > > is used in a subselect that's expected to return only one row, and it > > suddenly starts returning more, the query would raise an error. Seems > > better to err on the side of caution.) > > Yeah. Also, I realized from the citext regression tests that there's a > behavioral change even if you *don't* use the 'g' flag: the previous > behavior was to return a null on no match, but now you get zero rows out > instead. That's a fairly significant change. > > > I think we should keep the 1.0 version this time, in back branches. > > Agreed. Maybe we shouldn't even make 1.1 the default in the back > branches. > > Does 9.0 get different treatment? If (I'm not sure this is the case - or must be...) a pg_dump/pg_restore sequence against a back-branch database installs the default version of the extension for that PostgreSQL version I would agree; and, to clarify, we would still provide the ability to upgrade to citext-1.1 in back-branches. Alvaro >> and it (1.0) wouldn't be provided in the master branch Why wouldn't it? The whole point of versioning is to mark a release as stable/immutable and therefore eliminate any maintenance burden by simply refusing to maintain it. There is no maintainability reason to avoid shipping the previous versions that I can think of if the extension infrastructure works as advertised. Is there anywhere besides the source code that a user can read how extensions and pg_dump/pg_restore inter-operate in this manner? Neither pg_dump/restore nor CREATE EXTENSION cover the topic and there isn't a chapter called "upgrading" that would be a nice place to put such information... David J
