Re: libpq_r

Peter Eisentraut wrote:
> Bruce Momjian writes:
> 1. need to link in special libc_r (FreeBSD)
> 2. need to use magic flags for compiler and/or linker (FreeBSD, UnixWare)
> 3. need to compile with special preprocessor symbols (UnixWare, AIX)
> 4. need to use different compiler altogether (AIX)
>
> (If you read between the lines of the manufacturers' documentation, all
> these methods end up accomplishing similar things, they are only different
> interfaces for it.)
>
> If any of these cases apply, we need to provide a separate libpq_r, or
> else either threaded land or nonthreaded land will suffer pain, from what
> I read. (The simplest example is errno being defined in different ways
> and referring to different symbols.)
>
> If none of these cases apply, then a separate libpq_r will be redundant,
> perhaps "confusing" to some, but it can be ignored by the user.

I see no reason to symlink to libpq_r if it is identical to libpq.
Operating systems are moving away from _r libraries, and I see no reason
to create one just for consistency with platforms that still use _r.
Basically, I don't like the confusion.

I agree with the goal of having a libpq_r if it is different from libpq.

This is going to require us to compile libpq twice and install libpq and
libpq_r. Can that be done cleanly? I don't see how we can get this
done before beta. Will we fiddle with this during beta?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073