btree_gist extension - gbt_cash_union return type
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
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
I expect something is missing from the extension upgrade script to modify
the return type.
Is it safe/recommended to modify this function to return gbtreekey16?
Perhaps safer still to drop the extension and recreate it?
Thanks in advance. If this should be considered a bug, and there is a
better place to report such - please advise.
Tim
Tim Kane <tim.kane@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
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 <tgl@sss.pgh.pa.us> wrote:
Show quoted text
Tim Kane <tim.kane@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 areturn
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 gbtreekey8Hm. 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