On Fri, Dec 30, 2022 at 6:23 AM Andres Freund <andres@anarazel.de> wrote:
> On 2022-12-08 18:08:15 -0800, Andres Freund wrote:
> > On 2022-09-25 16:22:37 -0700, Andres Freund wrote:
> > The only alternative way to provide a wrapper that I can think of are to
> > a) introduce a new static library that can be linked to by libpqwalreceiver,
> > postgres_fdw, dblink
> > b) add a header with static inline functions implementing interrupt-processing
> > connection establishment for libpq
> >
> > Neither really has precedent.
> Any opinions? Due to the simplicity I'm currently leaning to a header-only
> helper, but I don't feel confident about it.
The header idea is a little bit sneaky (IIUC: a header that is part of
the core tree, but can't be used by core and possibly needs special
treatment in 'headercheck' to get the right include search path, can
only be used by libpqwalreceiver et al which are allowed to link to
libpq), but I think it is compatible with other goals we have
discussed in other threads. I think in the near future we'll probably
remove the concept of non-threaded server builds (as proposed before
in the post HP-UX 10 cleanup thread, with patches, but not quite over
the line yet). Then I think the server could be allowed to link libpq
directly? And at that point this code wouldn't be sneaky anymore and
could optionally move into a .c. Does that makes sense?
