On Tue, May 5, 2015 at 10:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@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...
