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