Re: citext operator precedence fix

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: citext operator precedence fix
Date: 2011-09-22 18:23:32
Message-ID: CA+TgmoZrOR-ZtZsGg55wOaHsz1e=idu0SVYyXVWOESAfysDwyw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 22, 2011 at 2:16 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Sep 22, 2011, at 11:14 AM, Kevin Grittner wrote:
>
>>> No, because if 1.1 was installed on 8.4, you'd need the commands
>>> to move all its functions into the extension, not re-create them.
>>
>> Shouldn't a version installed on 8.4 be installed as "unpackaged"?
>> Doesn't citext--unpackaged--1.0.sql contain the commands to move all
>> its functions into the extension?
>
> It contains everything need to move 1.0 functions into the extension. If Josh adds new functions they obviously would not be moved. So a new script would need to move them. And unpackaged--1.1 does not first run unpackaged--1.0.

I believe the point David is trying to make is that someone might take
an 9.2 version of a contrib module and manually install it on an 8.4
server by executing the install script, perhaps with some amount of
hackery.

But I don't think we're required to support that case. If the user
does a non-standard install, it's their job to deal with the fallout.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2011-09-22 18:30:54 Re: citext operator precedence fix
Previous Message David E. Wheeler 2011-09-22 18:16:37 Re: citext operator precedence fix