Feedback-ID: ie0a040ee:Fastmail
Message-ID: <afa52db5-a63f-4a43-90b3-7fd2872771db@eisentraut.org>
Date: Mon, 2 Jun 2025 09:31:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: SQL:2011 application time
To: Paul A Jungwirth <pj@illuminatedcomputing.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: 
 <CA+renyUApHgSZF9-nd-a0+OPGharLQLO=mDHcY4_qQ0+noCUVg@mail.gmail.com>
 <f061295a-d972-42b9-bf1b-90a833e3f686@illuminatedcomputing.com>
 <CACJufxHPQaD+q6o_AMg1PG6ETOWC=VqzN_=6QV9C5zbR8j=Tww@mail.gmail.com>
 <b4363a52-2279-4612-8953-1100fab0c772@illuminatedcomputing.com>
 <30dc3561-d7ab-42be-a1c5-096643423590@illuminatedcomputing.com>
 <b824fc91-f534-4096-8d94-de8e21b06915@illuminatedcomputing.com>
 <73d09e24-b6b9-4c89-8c0a-8842ca0f81f9@illuminatedcomputing.com>
 <c002230c-8879-4b2c-ad05-585d6572347c@illuminatedcomputing.com>
 <CACJufxESqArbu=R8m3a+ZF-Yia26KTGpEnyqz+8d5BXb1o=c=w@mail.gmail.com>
 <CACJufxECGaLjMcN8TJbX1fGrMFKs6qu+6RiZm98=sLcpiVpu2g@mail.gmail.com>
 <081aa43c-3a97-4bd5-a498-ba02e0a7570d@illuminatedcomputing.com>
 <54390149-11d6-4f52-bbe8-f69832ceb3bd@eisentraut.org>
 <eedaaca9-d615-4934-ab00-39ec376d9b37@eisentraut.org>
 <37ebb1d9-9036-485f-a215-e55435689917@eisentraut.org>
 <CA+renyWnEJOUb_Oq24Vy-X+7e+ynxVxknGm-P3+OQXmFD99tjw@mail.gmail.com>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: 
 <CA+renyWnEJOUb_Oq24Vy-X+7e+ynxVxknGm-P3+OQXmFD99tjw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/afa52db5-a63f-4a43-90b3-7fd2872771db%40eisentraut.org>
Precedence: bulk

On 26.05.25 23:18, Paul A Jungwirth wrote:
> On Sun, May 25, 2025 at 10:57 PM Peter Eisentraut <peter@eisentraut.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.