Re: SQL:2011 application time
От | Peter Eisentraut |
---|---|
Тема | Re: SQL:2011 application time |
Дата | |
Msg-id | afa52db5-a63f-4a43-90b3-7fd2872771db@eisentraut.org обсуждение исходный текст |
Ответ на | Re: SQL:2011 application time (Paul A Jungwirth <pj@illuminatedcomputing.com>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: