Re: pgsql: Fix assorted inconsistencies in GIN opclass support function dec

On Tue, May 3, 2016 at 12:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> > On Wed, Jan 20, 2016 at 6:32 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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