Обсуждение: Re: [GENERAL] Querying libpq compile time options
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. this was back a month or so ago. Would it be better to make a structure that has ALL the options, and return that from ONE function? If so, I can code it up. I have time available. -- 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
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. +
"Larry Rosenman" <lrosenman@pervasive.com> writes: > I had made a proposal to expose the path used for pg_service.conf. I don't remember that anymore, but my question about it would be "what's the use case?" I don't see a particularly good reason why an app would need to know that, whereas it's pretty clear why a thread-dependent app might wish to defend itself against a thread-unsafe libpq. regards, tom lane