Re: Fixing busted citext function declarations

On Tue, May 5, 2015 at 10:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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​