btree_gist extension - gbt_cash_union return type

Started by Tim Kanealmost 6 years ago3 messagesgeneral
Jump to latest
#1Tim Kane
tim.kane@gmail.com

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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Tim Kane (#1)
Re: btree_gist extension - gbt_cash_union return type

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

#3Tim Kane
tim.kane@gmail.com
In reply to: Tom Lane (#2)
Re: btree_gist extension - gbt_cash_union return type

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 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