Обсуждение: Re: [GENERAL] Querying libpq compile time options
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? -- 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: > 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. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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. regards, tom lane
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. +
Bruce Momjian <pgman@candle.pha.pa.us> writes: > True, but if you go per-option, I can see adding a lot of them. That > seemed more messy. If there actually were a lot of options being proposed for addition, maybe, but I only see one on the table. regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > True, but if you go per-option, I can see adding a lot of them. That > > seemed more messy. > > If there actually were a lot of options being proposed for addition, > maybe, but I only see one on the table. Well, SSL is one, multibyte is another. I can see it expanding. Locale? NLS? If we think it just threading, then that is easy, just one 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. +