Re: btree_gist extension - gbt_cash_union return type

From: Tim Kane <tim(dot)kane(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org>
Subject: Re: btree_gist extension - gbt_cash_union return type
Date: 2020-05-22 15:16:48
Message-ID: CADVWZZLDj5-U_dvMLA08QdTB3EhD0Q3hZzPYNJ8=MidNwPNDWA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Tim Kane <tim(dot)kane(at)gmail(dot)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
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Nico De Ranter 2020-05-22 15:17:57 Re: pg_dump crashes
Previous Message David G. Johnston 2020-05-22 15:16:34 Re: Query to get name a data type of a view