Обсуждение: Re: [GENERAL] Querying libpq compile time options

Поиск
Список
Период
Сортировка

Re: [GENERAL] Querying libpq compile time options

От
"Larry Rosenman"
Дата:
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


Re: [GENERAL] Querying libpq compile time options

От
Bruce Momjian
Дата:
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. +


Re: [GENERAL] Querying libpq compile time options

От
Tom Lane
Дата:
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


Re: [GENERAL] Querying libpq compile time options

От
Bruce Momjian
Дата:
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. +


Re: [GENERAL] Querying libpq compile time options

От
Tom Lane
Дата:
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


Re: [GENERAL] Querying libpq compile time options

От
Bruce Momjian
Дата:
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. +