Thread: Finding the pqlib version
I want to add the PQCancel() functionality to PyGreSQL. Until now, PyGreSQL works with PostgreSQL 7.3+, but unfortunately, PQCancel() is only available from 8.0+. In order to not break compilation of PyGreSQL on systems with PG7, I would like to do something like the following: #if PQLIB_VERSION_MAJOR < 8 PQRequestCancel(conn) #else c = PQgetCancel(conn) PQCancel(c, errbuf, 256) PQfreeCancel(c) #end However, there is no such thing as "PQLIB_VERSION_MAJOR". Anything else I could query instead? -- Christoph
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> However, there is no such thing as "PQLIB_VERSION_MAJOR".
> Anything else I could query instead?
Call "pg_config --version" and break it into pieces. To make life
easier, meld them back together into a single string with something
like this:
my $serverversion = sprintf("%d%.02d%.02d", $major_ver, $minor_ver, $patch);
Then you can do things like
if ($serverversion >= 80000) ...
and can similarly pass the above to cc via a -D and get some ifdef fun...
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200602110755
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFD7d8FvJuQZxSWSsgRAhuMAJ4sShLpZWOUUSFVbBqfnS4UB2GuTwCgnpgl
d3HjVGFhiS5H5xNf/M2qllU=
=z7X9
-----END PGP SIGNATURE-----
Christoph Zwerschke wrote: > However, there is no such thing as "PQLIB_VERSION_MAJOR". > Anything else I could query instead? You should query the presence of the function, not the version of the library. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Christoph Zwerschke wrote: > I want to add the PQCancel() functionality to PyGreSQL. > Until now, PyGreSQL works with PostgreSQL 7.3+, but > unfortunately, PQCancel() is only available from 8.0+. > > In order to not break compilation of PyGreSQL on systems with PG7, > I would like to do something like the following: > > #if PQLIB_VERSION_MAJOR < 8 > PQRequestCancel(conn) > #else > c = PQgetCancel(conn) > PQCancel(c, errbuf, 256) > PQfreeCancel(c) > #end > > However, there is no such thing as "PQLIB_VERSION_MAJOR". > Anything else I could query instead? You want the server version. In PostgreSQL 8.0 and later you can use libpq's PQserverVersion(), but for pre-8.0, I think you have to do SELECT version(), and parse that: test=> SELECT version(); version------------------------------------------------------------------PostgreSQL 8.2devel on i386-pc-bsdi4.3.1, compiledby GCC 2.95.3(1 row) I would also look how other interfaces are doing this. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Peter Eisentraut wrote: > You should query the presence of the function, not the version of the > library. Yes, but it will complicate things. I will probably have to use something like "configure" to do this. So far, this hasn't been necessary. So I'd prefer a simple hack. Or how would you to this? -- Christoph
Bruce Momjian wrote: > You want the server version. In PostgreSQL 8.0 and later you can use > libpq's PQserverVersion(), but for pre-8.0, I think you have to do > SELECT version(), and parse that: I'd prefer something defined in the Postgres include files that can be checked by the precompiler already. In Python, the version information with major, minor and micro is defined in patchlevel.h and can be used for conditional compilation. It would be nice if something like this existed also for Postgres. I noticed pg_config.h has PG_VERSION, but it is the compound version of major, minor and micro including the dots which cannot be easily compared. -- Christoph
Christoph Zwerschke <cito@online.de> writes:
> Yes, but it will complicate things. I will probably have to use
> something like "configure" to do this. So far, this hasn't been
> necessary. So I'd prefer a simple hack. Or how would you to this?
If you need to deal with more than one version of underlying code,
it's time to learn to use configure ...
regards, tom lane
Christoph Zwerschke wrote: > Peter Eisentraut wrote: > > You should query the presence of the function, not the version of the > > library. > > Yes, but it will complicate things. I will probably have to use > something like "configure" to do this. So far, this hasn't been > necessary. So I'd prefer a simple hack. Or how would you to this? I was wondering that myself. I am thinking you would need to use dlopen() to check for the symbol. Because the libpq version could change after you compile, I can't see how you could make it a configure check unless you said you don't allow changes to libpq after the build. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Christoph Zwerschke wrote: > Yes, but it will complicate things. I will probably have to use > something like "configure" to do this. So far, this hasn't been > necessary. So I'd prefer a simple hack. Or how would you to this? If you use distutils you can use the has_function method. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:> If you use distutils you can use the has_function method. Ok. That could be an alternative to using configure. -- Christoph
Bruce Momjian wrote:> I was wondering that myself. I am thinking you would need to use> dlopen() to check for the symbol. Because the libpq version could> change after you compile, I can't see how you could make it a> configure check unlessyou said you don't allow changes to libpq> after the build. The situation I was talking about is that you have a pre-compiled Python and PostgreSQL installed on your system, together with their header files, but you do not have the full source of Python and PostgreSQL available. I want to be able to compile PyGreSQL as a Python extension which is using functions from the python.dll and the libpq.dll, assuming that the installed header files match the installed dlls. -- Christoph
Peter Eisentraut wrote: > If you use distutils you can use the has_function method. Yes, after experimenting a little bit with distutils, I think that's the way to go for PyGreSQL. I can check with has_function first and then give a hint to the precompiler using define_macros. Thanks. -- Christoph
Christoph Zwerschke wrote: > Peter Eisentraut wrote: > > If you use distutils you can use the has_function method. > > Ok. That could be an alternative to using configure. And better because it is a run-time check rather than compile time. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Christoph Zwerschke wrote: > Bruce Momjian wrote: > > I was wondering that myself. I am thinking you would need to use > > dlopen() to check for the symbol. Because the libpq version could > > change after you compile, I can't see how you could make it a > > configure check unless you said you don't allow changes to libpq > > after the build. > > The situation I was talking about is that you have a pre-compiled Python > and PostgreSQL installed on your system, together with their header > files, but you do not have the full source of Python and PostgreSQL > available. I want to be able to compile PyGreSQL as a Python extension > which is using functions from the python.dll and the libpq.dll, assuming > that the installed header files match the installed dlls. Right, but assume you want to distribute that binary to others who might have a different version of libpq. This is required by packagers and a run-time test is best in those cases. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > Right, but assume you want to distribute that binary to others who might > have a different version of libpq. This is required by packagers and a > run-time test is best in those cases. Right. I see the point now: It makes a difference whether you want to create a redistributable binary package that would run on older systems or whether you want the package to be compileable on older systems. -- Christoph
On Sat, 2006-02-11 at 14:50 +0100, Peter Eisentraut wrote: > Christoph Zwerschke wrote: > > However, there is no such thing as "PQLIB_VERSION_MAJOR". > > Anything else I could query instead? > > You should query the presence of the function, not the version of the > library. If pqlib installed a pkg-config .pc file then this would be simpler. -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com
Murray Cumming wrote: > On Sat, 2006-02-11 at 14:50 +0100, Peter Eisentraut wrote: >> Christoph Zwerschke wrote: >>> However, there is no such thing as "PQLIB_VERSION_MAJOR". >>> Anything else I could query instead? >> You should query the presence of the function, not the version of the >> library. > > If pqlib installed a pkg-config .pc file then this would be simpler. Yes. You could use pg_config, but this is usually only included in the server package, not in the libs package. -- Christoph
Christoph Zwerschke wrote: > Yes. You could use pg_config, but this is usually only included in > the server package, not in the libs package. Example? -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Christoph Zwerschke wrote: >> Yes. You could use pg_config, but this is usually only included in >> the server package, not in the libs package. > > Example? The Windwows installer. pg_config is installed with the "database server" feature, not with the "libs" feature. For Linux I was wrong, it's in the devel package, not in server. -- Christoph
Christoph Zwerschke wrote: > The Windwows installer. pg_config is installed with the "database > server" feature, not with the "libs" feature. For Linux I was wrong, > it's in the devel package, not in server. That should be reported as a bug to the installer people. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:> Christoph Zwerschke wrote:>> The Windwows installer. pg_config is installed with the "database>>server" feature, not with the "libs" feature. For Linux I was wrong,>> it's in the devel package, not in server.>>That should be reported as a bug to the installer people. Which do you think would be the right package/feature category for pg_config for Linux/Windows? devel and Development->Tools/utilities? -- Christoph
On Wed, 2006-02-15 at 00:02 +0100, Christoph Zwerschke wrote: > Peter Eisentraut wrote: > > Christoph Zwerschke wrote: > >> The Windwows installer. pg_config is installed with the "database > >> server" feature, not with the "libs" feature. For Linux I was wrong, > >> it's in the devel package, not in server. > > > > That should be reported as a bug to the installer people. > > Which do you think would be the right package/feature category for > pg_config for Linux/Windows? devel and Development->Tools/utilities? I'm not sure what pg_config is. Maybe you are talking about something else. I am talking about pkg-config: http://pkgconfig.freedesktop.org/wiki/ http://www.openismus.com/documents/linux/using_libraries/using_libraries.shtml#cflagsandlibs It's very easy to provide it and it's easy to use. It's already hugely popular and used. -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com
Christoph Zwerschke wrote: > Which do you think would be the right package/feature category for > pg_config for Linux/Windows? devel and Development->Tools/utilities? I'm not sure what these categories are supposed to mean but they don't sound wrong. To gauge the correct placement I would say that whenever you install libpq-fe.h you should get pg_config in the same package/module/installation. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote:> Christoph Zwerschke wrote:>> Which do you think would be the right package/feature category for>>pg_config for Linux/Windows? devel and Development->Tools/utilities?>> I'm not sure what these categories are supposedto mean but they don't> sound wrong. To gauge the correct placement I would say that whenever> you install libpq-fe.hyou should get pg_config in the same> package/module/installation. The problem is that the Windows installer has the "Development" feature subdivided into "Include files", "Library files", "PGXS files" and "Tools and utilities". Installing pg_config along with the include files would be confusing in this case. By the way, putting the "Library files" under "Development" seems a bit unlucky, too. It should be on the top level instead. Where should such a suggestion be sent to? pgsql-patches? -- Christoph
Murray Cumming wrote:> Christoph Zwerschke wrote:>> Which do you think would be the right package/feature category for>>pg_config for Linux/Windows? devel and Development->Tools/utilities?>> I'm not sure what pg_config is. Maybe you aretalking about something> else. I am talking about pkg-config: pg_config is a PostgreSQL specific utility for roughly the same purpose: http://www.postgresql.org/docs/8.1/interactive/app-pgconfig.html So actually you don't need pkg-config here. -- Christoph
> >> Which do you think would be the right package/feature > category for >> pg_config for Linux/Windows? devel and > Development->Tools/utilities? > > > > I'm not sure what these categories are supposed to mean > but they don't > sound wrong. To gauge the correct > placement I would say that whenever > you install libpq-fe.h > you should get pg_config in the same > package/module/installation. > > The problem is that the Windows installer has the > "Development" feature subdivided into "Include files", > "Library files", "PGXS files" and "Tools and utilities". > Installing pg_config along with the include files would be > confusing in this case. > > By the way, putting the "Library files" under "Development" > seems a bit unlucky, too. It should be on the top level > instead. Where should such a suggestion be sent to? pgsql-patches? pginstaller-devel@pgfoundry.org - subscribe info on the project page http://pgfoundry.org/projects/pginstaller. Note that we can relatively easily put pg_config.exe under multiple locations (in the tree - still in the bin directory, but install can be triggered by different features). It just has to be made its own component. But I'm actually thinking we should perhaps put it as a base feature - along with libpq, being installed as soon as you install any part at all. Does that sound reasonable? //Magnus
Magnus Hagander wrote: > But I'm actually thinking we should perhaps put it as a base feature > - along with libpq, being installed as soon as you install any part > at all. Does that sound reasonable? No. As I said previously, pg_config really belongs together with the include files and the link libraries. Perhaps the categories are not so well chosen altogether. -- Peter Eisentraut http://developer.postgresql.org/~petere/
> > But I'm actually thinking we should perhaps put it as a base feature > > - along with libpq, being installed as soon as you install > any part at > > all. Does that sound reasonable? > > No. > > As I said previously, pg_config really belongs together with > the include files and the link libraries. But what about things like pg_config --bindir, pg_config --version, pg_config --sharedir etc - they are definitly usable even if you're not developing C language server extensions, aren't they? > Perhaps the categories are not so well chosen altogether. That I can agree with :-) I beleive they were originally split so you could change the directory used for each part. But I don't think we allow that anymore. What would ppl suggest? Put it all together as one feature? Or keep grouping in part? //Magnus
>> Perhaps the categories are not so well chosen altogether. > > That I can agree with :-) I beleive they were originally split so you > could change the directory used for each part. But I don't think we > allow that anymore. > > What would ppl suggest? Put it all together as one feature? Or keep > grouping in part? Yes, before deciding on where pg_config is put under Windows, we should first consider whether the categories should be rearranged. I think the fine granulation is ok, but if possible, the grouping in the Win installer should parallel the package categories under Unix on the first level. For instance, the libs are currently part of the devel category on Win, while they are a separate package on Unix. And I think you are right, --bindir, --sharedir and --version are pg_config features that could be interesting for any installation, not only if you compile something using the header files. -- Christoph
"Magnus Hagander" <mha@sollentuna.net> writes:
>> As I said previously, pg_config really belongs together with
>> the include files and the link libraries.
> But what about things like pg_config --bindir, pg_config --version,
> pg_config --sharedir etc - they are definitly usable even if you're not
> developing C language server extensions, aren't they?
Yes. pg_config started as strictly support for add-on makefiles but
it's evolved into something more than that. I'd vote for just dropping
it into the base package.
(Memo to self: should probably rearrange the Red Hat RPMs likewise.)
regards, tom lane
Am Mittwoch, 22. Februar 2006 00:17 schrieb Tom Lane: > Yes. pg_config started as strictly support for add-on makefiles but > it's evolved into something more than that. I'd vote for just dropping > it into the base package. > > (Memo to self: should probably rearrange the Red Hat RPMs likewise.) What would be the base package in that? -- Peter Eisentraut http://developer.postgresql.org/~petere/
Am Dienstag, 21. Februar 2006 21:38 schrieb Magnus Hagander: > But what about things like pg_config --bindir, pg_config --version, > pg_config --sharedir etc - they are definitly usable even if you're not > developing C language server extensions, aren't they? I can't imagine why. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
> Am Mittwoch, 22. Februar 2006 00:17 schrieb Tom Lane:
>> Yes. pg_config started as strictly support for add-on makefiles but
>> it's evolved into something more than that. I'd vote for just dropping
>> it into the base package.
>>
>> (Memo to self: should probably rearrange the Red Hat RPMs likewise.)
> What would be the base package in that?
postgresql-nvr ... I wouldn't stick it in -libs if that's what you were
wondering.
regards, tom lane