btree_gist extension - gbt_cash_union return type

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

btree_gist extension - gbt_cash_union return type

Tim Kane
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
Reply | Threaded
Open this post in threaded view
|

Re: btree_gist extension - gbt_cash_union return type

Tom Lane-2
Tim Kane <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: btree_gist extension - gbt_cash_union return type

Tim Kane
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 <[hidden email]> wrote:
Tim Kane <[hidden email]> 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