From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: SQL:2011 application time |
Date: | 2025-06-02 07:31:24 |
Message-ID: | afa52db5-a63f-4a43-90b3-7fd2872771db@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 26.05.25 23:18, Paul A Jungwirth wrote:
> On Sun, May 25, 2025 at 10:57 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>> Here we added a gist support function that we internally refer to by the
>> symbol GIST_STRATNUM_PROC. This translated from "well-known" strategy
>> numbers to opfamily-specific strategy numbers. However, we later
>> changed this to fit into index-AM-level compare type mapping, so this
>> function actually now maps from compare type to opfamily-specific
>> strategy numbers. So I'm wondering if this name is still good.
>>
>> Moreover, the index AM level also supports the opposite, a function to
>> map from strategy number to compare type. This is currently not
>> supported in gist, but one might wonder what this function is supposed
>> to be called when it is added.
>>
>> So I went through and updated the naming of the gist-level functionality
>> to be more in line with the index-AM-level functionality; see attached
>> patch. I think this makes sense because these are essentially the same
>> thing on different levels. What do you think? (This would be for PG18.)
>
> I agree this rename makes sense.
>
> Here do we want to say "respective operator class" instead of
> "respective operator family"? Or "operator class/family"? Technically
> btree_gist attaches it to the whole opfamily, but that's only because
> there is no appropriate ALTER OPERATOR CLASS functionality:
Thanks, I have committed it as is. The function is part of the operator
family; I guess there could be different interpretations about why that
is so, but I think this would introduce more confusion if we somehow
talked about operator classes in this context.
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiro Ikeda | 2025-06-02 07:32:40 | Re: Assertion failure in smgr.c when using pg_prewarm with partitioned tables |
Previous Message | jian he | 2025-06-02 06:49:45 | tab complete for ALTER TABLE ALTER CONSTRAINT |