public inbox for [email protected]  

help / color / mirror / Atom feed

From: Bertrand Drouvot <[email protected]>
To: Jelte Fennema-Nio <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: [email protected]
Subject: Re: Safer hash table initialization macro
Date: Wed, 14 Jan 2026 09:28:37 +0000
Message-ID: <aWdhxU/[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CA+hUKG+TuQPXtfkaam6trfLrk+OXf89zUt7Jx27zEY-y8i1swA@mail.gmail.com>
	<CAGECzQSnhom3wFnY6a7xepGfxzzVmwyNCcJQE=y8UYS-g2G=RQ@mail.gmail.com>
	<CA+hUKGLZPZ4DgJs46-dkkkF5pi0gm23SerJY0HbOUP5r7siPsg@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<aWdMaa/[email protected]>
	<[email protected]>

Hi,

On Wed, Jan 14, 2026 at 09:46:41AM +0100, Jelte Fennema-Nio wrote:
> On Wed, 14 Jan 2026 at 08:57, Bertrand Drouvot <[email protected]> wrote:
> > + * WARNING: If you use char[N] to store binary data that is not null-terminated,
> > + * the automatic detection will incorrectly treat it as a string and use string
> > + * comparison. In such cases, use hash_make_ext() with .force_blobs = true to
> > + * override the automatic detection
> > 
> > maybe s/is not null-terminated/may contain null bytes/?
> 
> Changed wording and changed to NOTE.

Thanks, looks good.

> So if we don't have the foreach_hash_with_hash_value macro treat 0
> special, then we'd need to replace this single while with two for
> foreach loops. A foreach_hash for the 0 case and a
> foreach_hash_with_hash_value for the non-zero one.

Okay, let's forget about introducing foreach_hash_with_hash_value() then.

> > -static void
> > -cfunc_hashtable_init(void)
> > -{
> > -       /* don't allow double-initialization */
> > -       Assert(cfunc_hashtable == NULL);
> > 
> > Most of the hash_make_fn_cxt() callers check that the destination is already
> > NULL so that removing the Assert() is not that worrying for them. There are 2
> > places where it's not the case: InitializeAttoptCache() and build_guc_variables()
> > , should we add an Assert (or an if check) in them? I think that an Assert is
> > more appropriate for those 2.
> 
> I'm a bit confused about this comment. I didn't change anything for
> those two places about their checks for NULL. Did you mean this as a
> separate but related improvement to existing code?

Agree that you didn't change for NULL check in those places.
I meant that 0003 introduced calling hash_make_fn_cxt() in InitializeAttoptCache()
and build_guc_variables(), which made me think if we could add an Assert while
at it.

> (To be clear, the removed Assert that you quoted doesn't matter when
> inlining, because it's the only item in an if (!cfunc_hashtable) block)

Right, the removed Assert is fine.

> 
> As long as the new macro definitions get in, any way a committer thinks
> that's sensible is fine by me. e.g. The List foreach macros also haven't
> been replaced in bulk, but I'm still very happy that I can use them for
> new code.

+1

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

view thread (6+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Safer hash table initialization macro
  In-Reply-To: <aWdhxU/[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox