> > > Yes, and a flag to ecpg. Added to TODO:
> > Um, it's not clear *when* you need to know this:
> > - application configure time?
> > - application compile time?
> > - application link time?
> > - application run time?
> > Of those possibilities, "add a function" responds to only one, and
> > it's the one I can see least use-case for. I should think that by
> > run-time it's probably too late to do much about it other than fail.
> Yea, I am thinking a libpq function would say "libpq not thread-safe'
> and return an error. I would think pg_config output would be
> fine for any link or compile-time check.
Another idea might be to compile the library with a different name when
it's thread safe. And if your system supports it, we build both by
default. (libpq and libpqt or something).
pgsql-hackers by date
|Next:||From: Mark Wong||Date: 2005-08-29 15:19:58|
|Subject: Re: Simplifying wal_sync_method|
|Previous:||From: Tom Lane||Date: 2005-08-29 15:13:29|
|Subject: Re: [HACKERS] Improved \df(+) in psql + backward-compatibility |