Re: pgsql: Introduce hash_search_with_hash_value() function

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Alexander Korotkov <akorotkov(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Introduce hash_search_with_hash_value() function
Date: 2024-08-07 20:25:12
Message-ID: CAPpHfdtSh9JrxJgYyoivKPrPUi=gqGbfOqSr=V5=9otkj2Fe4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Wed, Aug 7, 2024 at 1:34 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> st 7. 8. 2024 v 12:22 odesílatel Alexander Korotkov <aekorotkov(at)gmail(dot)com> napsal:
>> Thank you.
>> Please see 40064a8ee1 takes special efforts to match HTAB hash
>> function to syscache hash function. By default, their hash values
>> don't match and you can't simply use syscache hash value to search
>> HTAB. This probably should be mentioned in the header comment of
>> hash_seq_init_with_hash_value().
>
>
> yes, enhancing doc should be great + maybe assert

Please check the patch, which adds a caveat to the function header
comment. I don't particularly like an assert here, because there
could be use-cases besides syscache callbacks, which could legally use
default hash function.

------
Regards,
Alexander Korotkov
Supabase

Attachment Content-Type Size
v1-0001-Add-a-caveat-to-hash_seq_init_with_hash_value-hea.patch application/octet-stream 1.4 KB

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Michael Paquier 2024-08-07 23:15:44 Re: pgsql: Fix more holes with SLRU code in need of int64 for segment numbe
Previous Message Alexander Korotkov 2024-08-07 20:08:45 Re: pgsql: Introduce hash_search_with_hash_value() function

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema-Nio 2024-08-07 20:42:08 Re: Add trim_trailing_whitespace to editorconfig file
Previous Message Robert Haas 2024-08-07 20:10:27 Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs