| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Thread-safe getopt() |
| Date: | 2026-03-30 14:43:19 |
| Message-ID: | 600286f9-fdc3-4d6e-8458-9bfcc729d228@iki.fi |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 30/03/2026 17:34, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2026-03-30 14:44:30 | Re: Skipping schema changes in publication |
| Previous Message | Daniel Gustafsson | 2026-03-30 14:43:15 | Re: Changing the state of data checksums in a running cluster |