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

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

The admin needs to know it to use it.  Currently there is no
way to get what is compiled into a specific libpq.

>
>> 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.

I guess I'll just crawl under my rock again.



--
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:
> >> 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?
> 
> The admin needs to know it to use it.  Currently there is no 
> way to get what is compiled into a specific libpq. 

Uh, it is an _admin_ function, not an application programmer 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. +