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. +
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
