Re: [GENERAL] Querying libpq compile time options - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [GENERAL] Querying libpq compile time options
Date
Msg-id 200605171715.k4HHFsx27673@candle.pha.pa.us
Whole thread Raw
In response to Re: [GENERAL] Querying libpq compile time options  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] Querying libpq compile time options
List pgsql-hackers
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. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] Querying libpq compile time options
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Querying libpq compile time options