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

Bruce Momjian wrote:
> 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.

I had made a proposal to expose the path used for pg_service.conf.

this was back a month or so ago.

Would it be better to make a structure that has ALL the options, and
return
that from ONE function?

If so, I can code it up.  I have time available.



--
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:
> Bruce Momjian wrote:
> > 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.
> 
> I had made a proposal to expose the path used for pg_service.conf.  

Why would an application programmer care to know the location of
pg_service.conf?

> Would it be better to make a structure that has ALL the options, and
> return
> that from ONE function?

I can't think of an easy way to do that.

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

"Larry Rosenman" <lrosenman@pervasive.com> writes:
> I had made a proposal to expose the path used for pg_service.conf.  

I don't remember that anymore, but my question about it would be "what's
the use case?"  I don't see a particularly good reason why an app would
need to know that, whereas it's pretty clear why a thread-dependent app
might wish to defend itself against a thread-unsafe libpq.
        regards, tom lane