Hi, On 2022-12-30 10:31:22 +1300, Thomas Munro wrote: > 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.
Hm, what special search path / headerscheck magic are you thinking of? I think something like src/include/libpq/libpq-be-fe-helpers.h defining a bunch of static inlines should "just" work? We likely could guard against that header being included from code ending up in the postgres binary directly by #error'ing if BUILDING_DLL is defined. That's a very badly named define, but it IIRC has to be iff building code ending up in postgres directly. > 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? I was wondering about linking in libpq directly as well. But I am not sure it's a good idea. I suspect we'd run into some issues around libraries (including extensions) linking to different versions of libpq etc - if we directly link to libpq that'd end up in tears. It might be a different story if we had a version of libpq built with different symbol names etc. But that's not exactly trivial either. Greetings, Andres Freund
