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?
