Magnus Hagander wrote:
> > > The following patch addresses this issue by making libpgport usable
> > > unchanged by client applications, and makes a special
> > server version
> > > for the backend.
> >
> > This raises some alarm bells for me. Why does a "port
> > support" library need to distinguish whether it is running in
> > frontend or backend?
>
> Just from the problems I've seen with several modules - ereport().
> Several functions use ereport() if !FRONTEND and something else if
> FRONTEND.
>
> I've seen this problem several times when trying to compile things "out
> of sync". The main issue is that the port stuff behave differently,
> certainly. I originally thought the deal was that anything that relied
> on backend stuff would go in backend/port, but there are (and has been
> since before I started looking at it) several files in /port/ taht rely
> heavily on functions and variables in the backend.
The basic issue is ereport and memory allocation for dirmod, ereport for
exec.c, thread-safety for getaddrinfo and thread.c. I can't think of
how to cleanly abstract them so the backend and libpq have compatibile
versions to call so I can use the same object file, so I made new
libraries.
And as Magnus has pointed out, they do get out of sync too easily
without this cleanup.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
