Re: Remove hardcoded hash opclass function signature exceptions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Remove hardcoded hash opclass function signature exceptions
Date: 2024-09-06 19:43:55
Message-ID: 2366111.1725651835@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> hashvalidate(), which validates the signatures of support functions for
> the hash AM, contains several hardcoded exceptions.
> ...
> This patch removes those exceptions by providing new support functions
> that have the proper declared signatures. They internally share most of
> the C code with the "wrong" functions they replace, so the behavior is
> still the same.

+1 for cleaning this up. A couple of minor nitpicks:

* I don't really like the new control structure, or rather lack of
structure, in hashvalidate. In particular the uncommented
s/break/continue/ changes look like typos. They aren't, but can't
you do this in a less confusing fashion? Or at least add comments
like "continue not break because the code below the switch doesn't
apply to this case".

* Hand-picking OIDs as you did in pg_proc.dat is kind of passé now.
I guess it's all right as long as nobody else does the same thing in
the near future, but ...

> Not done here, but maybe hashvarlena() and hashvarlenaextended() should
> be removed from pg_proc.dat, since their use as opclass support
> functions is now dubious.

I wish we could get rid of those, but according to
codesearch.debian.net, postgis and a couple of other extensions are
relying on them. If we remove them we'll break any convenient upgrade
path for those extensions.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-09-06 19:47:35 Re: AIO v2.0
Previous Message Andres Freund 2024-09-06 19:38:16 Re: AIO v2.0