Обсуждение: Re: [GENERAL] Querying libpq compile time options
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> I thought about this. Attached is a patch you can use to
>> popen("pg_config") and then look for the thread flag to configure.
>> One idea would be to add this sample to our libpq documentation. The
>> problem with the example is popen() overhead, pg_config not in
>> $PATH, or pg_config's version not matching libpq's version.
>
> Yeah, the last point seems like a killer objection :-(. It'd be
> better to add some sort of libpq function to handle the issue.
>
and when I've proposed libpq functions to expose compile-time
constants, I've been shot down.
How is this different?
--
Larry Rosenman
Database Support Engineer
PERVASIVE SOFTWARE. INC.
12365B RIATA TRACE PKWY
3015
AUSTIN TX 78727-6531
Tel: 512.231.6173
Fax: 512.231.6597
Email: Larry.Rosenman@pervasive.com
Web: www.pervasive.com
Larry Rosenman wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> I thought about this. Attached is a patch you can use to
> >> popen("pg_config") and then look for the thread flag to configure.
> >> One idea would be to add this sample to our libpq documentation. The
> >> problem with the example is popen() overhead, pg_config not in
> >> $PATH, or pg_config's version not matching libpq's version.
> >
> > Yeah, the last point seems like a killer objection :-(. It'd be
> > better to add some sort of libpq function to handle the issue.
> >
>
> and when I've proposed libpq functions to expose compile-time
> constants, I've been shot down.
>
> How is this different?
No idea, what is the URL of your proposal. Keep in mind this is not
option-specific.
-- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Tom Lane wrote:
>>> Yeah, the last point seems like a killer objection :-(. It'd be
>>> better to add some sort of libpq function to handle the issue.
>>
>> and when I've proposed libpq functions to expose compile-time
>> constants, I've been shot down.
>>
>> How is this different?
> No idea, what is the URL of your proposal. Keep in mind this is not
> option-specific.
Hm, I was thinking of something like "bool PQisThreadSafe()". It sounds
like Bruce is thinking of something that'd return a string literal
containing configure flags and then apps would have to try to inspect
that to determine what they want to know. That seems fairly messy to
me; for one thing because it would imply wiring assumptions about
default configure flags into apps, and that's something that could
change over time.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> Tom Lane wrote: > >>> Yeah, the last point seems like a killer objection :-(. It'd be > >>> better to add some sort of libpq function to handle the issue. > >> > >> and when I've proposed libpq functions to expose compile-time > >> constants, I've been shot down. > >> > >> How is this different? > > > No idea, what is the URL of your proposal. Keep in mind this is not > > option-specific. > > Hm, I was thinking of something like "bool PQisThreadSafe()". It sounds > like Bruce is thinking of something that'd return a string literal > containing configure flags and then apps would have to try to inspect > that to determine what they want to know. That seems fairly messy to > me; for one thing because it would imply wiring assumptions about > default configure flags into apps, and that's something that could > change over time. True, but if you go per-option, I can see adding a lot of them. That seemed more messy. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> True, but if you go per-option, I can see adding a lot of them. That
> seemed more messy.
If there actually were a lot of options being proposed for addition,
maybe, but I only see one on the table.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > True, but if you go per-option, I can see adding a lot of them. That > > seemed more messy. > > If there actually were a lot of options being proposed for addition, > maybe, but I only see one on the table. Well, SSL is one, multibyte is another. I can see it expanding. Locale? NLS? If we think it just threading, then that is easy, just one function. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +