From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tim Kane <tim(dot)kane(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: btree_gist extension - gbt_cash_union return type |
Date: | 2020-05-22 14:44:09 |
Message-ID: | 26541.1590158649@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2020-05-22 14:47:15 | Re: pg_dump crashes |
Previous Message | Greg Nolle | 2020-05-22 14:42:46 | Re: Inaccurate (sometimes wildly so) row estimates for simple join |