Re: pgsql: Fix assorted inconsistencies in GIN opclass support function dec
От | Alexander Korotkov |
---|---|
Тема | Re: pgsql: Fix assorted inconsistencies in GIN opclass support function dec |
Дата | |
Msg-id | CAPpHfdtKmQ=bTgs605TZ5UubEzfTa=c9xNkrHjg-OkOcdkOt4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Fix assorted inconsistencies in GIN opclass support function dec (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: pgsql: Fix assorted inconsistencies in GIN opclass support function dec
|
Список | pgsql-committers |
On Tue, May 3, 2016 at 12:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> On Wed, Jan 20, 2016 at 6:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> contrib/hstore/hstore--1.3.sql | 12 ++++-----
>> contrib/intarray/intarray--1.1.sql | 8 +++---
>> contrib/tsearch2/tsearch2--1.0.sql | 4 +--
> Hmm... Is it correct to change function signatures without extension
> version bump? pg_upgraded clusters would remain with old version of these
> functions. Once we have instances with same extension version but with
> different signatures of its functions, there is no correct way to refer
> these functions in future. I think we should do the version bump in this
> case.
It doesn't really matter, though, because there simply isn't any need to
refer to these functions from SQL. They are only useful as opclass
support functions.
What if we'll want to reuse some on these functions in new opclass?
Assumption that we don't need to refer these functions from SQL seems dangerous to me.
If pg_upgraded instances are OK to leave with old function definitions, why do we bother about new instances?
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
В списке pgsql-committers по дате отправления: