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

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

Re: [GENERAL] Querying libpq compile time options

От
"Larry Rosenman"
Дата:
Bruce Momjian wrote:
> 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.
but libpq is the only thing that knows where it is, and I had proposed a
way
for psql to use the function to get it.

However, I'm going to forget about it, as obviously I won't get approval
for it.



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

От
Tom Lane
Дата:
"Larry Rosenman" <lrosenman@pervasive.com> writes:
>> Uh, it is an _admin_ function, not an application programmer
>> function.

> but libpq is the only thing that knows where it is, and I had proposed a
> way for psql to use the function to get it.

It'd make more sense for pg_config to expose this as one of the
available information bits.  The difference from the thread-support
case is that you'd typically want to get the pg_service.conf location
manually, and that's exactly what pg_config is designed for.  Verifying
thread support, on the other hand, is something that a program would
want to do.
        regards, tom lane


Re: [GENERAL] Querying libpq compile time options

От
Bruce Momjian
Дата:
Tom Lane wrote:
> "Larry Rosenman" <lrosenman@pervasive.com> writes:
> >> Uh, it is an _admin_ function, not an application programmer
> >> function.
> 
> > but libpq is the only thing that knows where it is, and I had proposed a
> > way for psql to use the function to get it.
> 
> It'd make more sense for pg_config to expose this as one of the
> available information bits.  The difference from the thread-support

We already do expose it:
$ pg_config --sysconfdir/usr/var/local/postgres/etc

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

От
Andrew Dunstan
Дата:
Bruce Momjian wrote:
> We already do expose it:
>
>     $ pg_config --sysconfdir
>     /usr/var/local/postgres/etc
>
>   

Speaking of this item, what do we want to do about the Windows situation 
where if the directory doesn't exist it reports nothing at all? I am 
inclined to send back the output from GetFullPathName() instead of 
GetShortPathName(). This should be fixed - reporting an empty string is 
fairly unsatisfactory.

cheers

andrew



Re: [GENERAL] Querying libpq compile time options

От
Bruce Momjian
Дата:
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> > We already do expose it:
> >
> >     $ pg_config --sysconfdir
> >     /usr/var/local/postgres/etc
> >
> >   
> 
> Speaking of this item, what do we want to do about the Windows situation 
> where if the directory doesn't exist it reports nothing at all? I am 
> inclined to send back the output from GetFullPathName() instead of 
> GetShortPathName(). This should be fixed - reporting an empty string is 
> fairly unsatisfactory.

I was researching that and will report back.

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