Re: [BUGS] ltree::text not immutable? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [BUGS] ltree::text not immutable?
Date
Msg-id CA+TgmoZDsWoK_FEq74Q7_qf9LzRA71euxMpJCWV+o8RVTSMXhA@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] ltree::text not immutable?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Nov 6, 2014 at 5:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> On 11/5/14, 7:38 PM, Robert Haas wrote:
>>> I don't understand why you went to all the trouble of building a
>>> versioning system for extensions if you're not going to use it.
>
>> I was about to dismiss this comment since I don't see any real need  for a version bump here, except that AFAIK
there'sno way to upgrade an extension without bumping the version, other than resorting to hackery.
 
>
> Well, the one or two users who actually care can fix the problem with a
> manual ALTER FUNCTION.  I'm not sure it's worth making everyone else
> jump through update hoops.  If it hadn't taken us years to even notice
> the issue, I might be more willing to expend work here, but I really
> doubt the audience is larger than one or two people ...

I think that's missing the point.  If you bump the version, nobody is
compelled to update.  If you don't, they can't, even if they want to.
This is exactly the opposite of situation from bumping catversion:
bumping catversion forces people to re-initdb, even if they don't care
about picking up the revised catalog contents, but bumping the
extension version does not do that.  It just makes it difficult for
people who want to get the benefit of the changes to do so.

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Defining dedicated macro to grab a relation's persistence
Next
From: Alvaro Herrera
Date:
Subject: Re: Proposal: Log inability to lock pages during vacuum