Re: [BUGS] ltree::text not immutable?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [BUGS] ltree::text not immutable?
Дата
Msg-id CA+TgmoZDsWoK_FEq74Q7_qf9LzRA71euxMpJCWV+o8RVTSMXhA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [BUGS] ltree::text not immutable?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Defining dedicated macro to grab a relation's persistence
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Proposal: Log inability to lock pages during vacuum