Wayne Fang <wayne@barrodale.com> writes:
> For various reasons (parallel structure with existing code,
> commonality of concepts, etc), we have C language functions
> implemented that use libpq to make a new connection to the same
> Postgres server. Yes, I realize libpq is meant for clients and SPI
> for backends. The question is, are there any technical problems with
> this? Will using libpq in the backend do Bad Things in unexpected
> areas/ways?
dblink does that, and I've not heard of problems, though there are
certain specific areas where you'd need to be careful due to overlap of
symbols between libpq and backend (the DLxxx functions used for
listen/notify are one such place, and there are conflicts in the
pg_wchar stuff as well). It'd be a good idea to make sure that your
custom functions will bind first to libpq and only second to the main
backend's symbols.
By the same token, don't try to link libpq statically into the backend.
But it should be possible to make it work as a dynamic link.
Realize also that this is *fundamentally* different from SPI, in that
you are controlling a separate session rather than issuing commands in
your own session. This has implications for data visibility, error
recovery, and so on. But you probably knew that already.
regards, tom lane