On Fri, Dec 30, 2022 at 6:23 AM Andres Freund <and...@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?
