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