On 30/03/2026 17:34, Tom Lane wrote:
Heikki Linnakangas <[email protected]> writes:
Here's a patch for a thread-safe version of getopt(). I implemented it
as two functions, pg_getopt_start() and pg_getopt_next(). Since
there's no standard to follow, we have freedom on how to implement it,

Why in the world would we invent our own getopt API rather than
just replacing the relevant state variables with thread-local ones,
entirely internally to getopt.c?

It's not like this is a performance-critical code path.  I think
the cognitive load for developers of having to learn YA API should
weigh against doing things this way.

The new API is very similar to the same as the plain getopt() API, it'll be quickly recognizable to anyone who's familiar with getopt().

Thread-local variables would work too, but I think we'd need to give them different names anyway to avoid conflicting with the plain getopt() global variables.

- Heikki



Reply via email to