Querying libpq compile time options

spaminos-sql@yahoo.com wrote:

Hi all

I am writing an app that uses libpq, but because it is threaded I want to make sure that the dynamic library being used has been compiled with the right option.
How do I do this?

Is there a call such as "bool PQisThreadSafe()" that I can call?

[ Email moved to hackers list.]

Good question. This has come up a few times. You can check if the
installation has threading with "pg_config --configure", and I though
there was a way to test at runtime, but looking I don't see anything.

Is this like detecting of libpq is SSL-enabled? I see PQgetssl(). Do
we need to add a libpq function to return true/false for threading?
Slony requires a threaded libpq, so it could do the test to prevent
wrong configurations. It would be nice to enabled threading by default,
but it is like SSL in that not all operating systems support it.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

From: Bruce Momjian <pgman@candle.pha.pa.us>

spaminos-sql@yahoo.com wrote:

Hi all

I am writing an app that uses libpq, but because it is threaded I want to make sure that the dynamic
library being used has been compiled with the right option.
How do I do this?

Is there a call such as "bool PQisThreadSafe()" that I can call?

Is this like detecting of libpq is SSL-enabled? I see PQgetssl(). Do
we need to add a libpq function to return true/false for threading?
Slony requires a threaded libpq, so it could do the test to prevent
wrong configurations. It would be nice to enabled threading by default,
but it is like SSL in that not all operating systems support it.

Yes, this is exactly the issue I have: I want to enforce at runtime that the library being
used is correct.
btw, I noticed that for some reason the prebuild linux rpms for Fedora Core 3 are compiled
without pthread support (and that's how I found out that I had to check the library on startup as I was getting strange lockups).
I think the simplest is to add a new call just like the one you described for testing for ssl and tell people
to call this function if they need the library to be thread safe.

Nicolas

On Fri, May 12, 2006 at 08:38:07PM -0400, Bruce Momjian wrote:

Is this like detecting of libpq is SSL-enabled? I see PQgetssl(). Do
we need to add a libpq function to return true/false for threading?
Slony requires a threaded libpq, so it could do the test to prevent
wrong configurations. It would be nice to enabled threading by default,
but it is like SSL in that not all operating systems support it.

PQgetssl() doesn't tell you if SSL is supported, it tells you if the
*current connection* is using OpenSSL, which is similar but not the
same.

There is AFAIK no way to tell if SSL support is compiled in. Part of
the patch I posted for GnuTLS support answered this question also
(PQgettlsinfo()).

Have a ncie day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Martijn van Oosterhout wrote:
-- Start of PGP signed section.

On Fri, May 12, 2006 at 08:38:07PM -0400, Bruce Momjian wrote:

Is this like detecting of libpq is SSL-enabled? I see PQgetssl(). Do
we need to add a libpq function to return true/false for threading?
Slony requires a threaded libpq, so it could do the test to prevent
wrong configurations. It would be nice to enabled threading by default,
but it is like SSL in that not all operating systems support it.

PQgetssl() doesn't tell you if SSL is supported, it tells you if the
*current connection* is using OpenSSL, which is similar but not the
same.

There is AFAIK no way to tell if SSL support is compiled in. Part of
the patch I posted for GnuTLS support answered this question also
(PQgettlsinfo()).

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.

A more comprehensive idea would be to embed the configure string in
libpq, like we do for pg_config, and allow that to be returned to the
caller so they can do a strstr() to see if a certain flag was used.

Having per-configure flag functions, like for threading, seems like it
could be a mess because there is a lot more application programmers might
care about in addition to threading, like SSL, multi-byte, etc.

--
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:

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.

regards, tom lane

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

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

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

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

"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

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

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.

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.

I guess I'll just crawl under my rock again.

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

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

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

Bruce Momjian wrote:

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.

but libpq is the only thing that knows where it is, and I had proposed a
way
for psql to use the function to get it.

However, I'm going to forget about it, as obviously I won't get approval
for it.

--
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" <lrosenman@pervasive.com> writes:

Uh, it is an _admin_ function, not an application programmer
function.

but libpq is the only thing that knows where it is, and I had proposed a
way for psql to use the function to get it.

It'd make more sense for pg_config to expose this as one of the
available information bits. The difference from the thread-support
case is that you'd typically want to get the pg_service.conf location
manually, and that's exactly what pg_config is designed for. Verifying
thread support, on the other hand, is something that a program would
want to do.

regards, tom lane

Tom Lane wrote:

"Larry Rosenman" <lrosenman@pervasive.com> writes:

Uh, it is an _admin_ function, not an application programmer
function.

but libpq is the only thing that knows where it is, and I had
proposed a way for psql to use the function to get it.

It'd make more sense for pg_config to expose this as one of the
available information bits. The difference from the thread-support
case is that you'd typically want to get the pg_service.conf location
manually, and that's exactly what pg_config is designed for.
Verifying thread support, on the other hand, is something that a
program would want to do.

It still gets into the messiness of pg_config doesn't load libpq, and
there could be a mis-match.

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