On Tue, May 3, 2016 at 12:09 AM, Tom Lane <[email protected]> wrote:
> Alexander Korotkov <[email protected]> writes: > > On Wed, Jan 20, 2016 at 6:32 AM, Tom Lane <[email protected]> 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
