Thank you Tom, I appreciate the thorough explanation. Good to confirm that it’s of no consequence.
Tim On Fri, 22 May 2020 at 15:44, Tom Lane <t...@sss.pgh.pa.us> wrote: > Tim Kane <tim.k...@gmail.com> writes: > > I've noticed a discrepancy in the return type for the gbt_cash_union > > function... > > On fresh instances of postgres 9.6.11, where the btree_gist extension is > > newly created (version 1.2) yields a gbt_cash_union function with a > return > > type of gbtreekey16 > > ... which is correct. > > > While instances that have been upgraded from 9.6.2 to 9.6.11, where the > > btree_gist was originally installed as 1.0 and then upgraded from 1.0 to > > 1.2 - that same function has a return type of gbtreekey8 > > Hm. I think this is an oversight in commit 749a787c5; we were focused > on fixing the functions' argument types and forgot that there were any > return-type changes. > > However, I'm not too fussed about it. Nothing checks those signatures > at run-time, so it's basically cosmetic. The reason for the pushups > in 749a787c5 was to ensure that we could name the functions in ALTER > FUNCTION; but that just depends on the argument types, so it's not > a reason to worry either. > > > Is it safe/recommended to modify this function to return gbtreekey16? > > I wouldn't sweat about it. If you did want to fix it, it'd have to be > a manual UPDATE on pg_proc, there not being any ALTER FUNCTION way > to do it. On the whole, the risk of fat-fingering the update and > thereby hosing your database seems to outweigh any benefit. > > > Perhaps safer still to drop the extension and recreate it? > > That would force dropping the indexes that depend on it, so > it seems like a big overreaction. > > regards, tom lane >
