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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
