Re: [HACKERS] Module dependency on PostgeSQL version
This is what I currently have: #if (CATALOG_VERSION_NO = 200211021) #define PG_VERSION_73_COMPAT #elif (CATALOG_VERSION_NO = 200310211) #define PG_VERSION_74_COMPAT #else #define PG_VERSION_75_COMPAT #endif Since CATALOG_VERSION_NO doesn't change between major releases, it seems to work pretty well. Joe Ok, thanks for the tip. Somewhat cleaner than what I suggested. Your solution doesn't cover the situations when you have dependencies on patch versions though, does it? There's no way to distinguish between 7.4.1 and 7.4.2 if the catalog version doesn't change. Such situations will arise. A module author finds a bug in the backend, reports it, and creates a less than perfekt work-around in his own code. At some point the bug gets properly fixed and included in some patch release. Using that release, the work-around is obsolete. I had an example when this happened a while back (concerning loss of MemoryContext between function ivocations). My workaround was really ugly (using the parent MemoryContext) and could potentially waste a lot of memory so it was imperative to actually get rid of it as soon as the patch was released. regards, Thomas Hallgren ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Module dependency on PostgeSQL version
Greg Sabino Mullane [EMAIL PROTECTED] wrote in message
DBD::Pg uses pg_config --version and parses the output to set the
version information before compiling. It finds pg_config by using
PG envrironment variables, or looks in the path. Once running, it
does a SELECT version() to find out what server it is running
against. Whenever possible, is now uses the new protocol version
information. It's much handier to just say:
if (protocol=3) {
...
}
Great! The SELECT version() approach has the advantage of having an
already compiled version adapt to different versions of the backend. I'll
try and use that to overcome differences in patch levels.
Thanks,
Thomas Hallgren
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Module dependency on PostgeSQL version
Joe Conway wrote: #if (CATALOG_VERSION_NO = 200211021) #define PG_VERSION_73_COMPAT Since CATALOG_VERSION_NO doesn't change between major releases, it seems to work pretty well. That approach also has the nice property that it already works for all releases back to 7.0, whereas anything we add now would only be useful starting in 7.5 ... Thomas Hallgren [EMAIL PROTECTED] writes: Your solution doesn't cover the situations when you have dependencies on patch versions though, does it? There's no way to distinguish between 7.4.1 and 7.4.2 if the catalog version doesn't change. Perhaps not, but I think it would be pretty risky to depend on an #ifdef to tell you which backend minor version you're running in anyway. Addon libraries are unlikely to get upgraded at the same times that the backend does, so it's certainly plausible that you could be running in a later minor release than you were compiled with. If people copy executables between machines then the reverse is easily possible too. The only real version tiedown we have at the moment is to put extension libraries into a PG-version-specific $libdir, and that is not going to narrow things more closely than the PG major version in most setups. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Module dependency on PostgeSQL version
Thomas Hallgren [EMAIL PROTECTED] writes: The PGSQL_MAJOR_VER and PGSQL_MINOR_VER does not exist today. Ideally, I'd like to find them in src/Makefile.global. Only thing present seems to be the VERSION. I'd like to see something like: PGSQL_MAJOR_VER := 7 PGSQL_MINOR_VER := 5 PGSQL_PATCH_VER := devel VERSION := $(PGSQL_MAJOR_VER).$(PGSQL_MINOR_VER).$(PGSQL_PATCH_VER) To be used in CPPFLAGS as: -DPGSQL_MAJOR_VER=$(PGSQL_MAJOR_VER) etc. Wouldn't it be better to just put those #defines in to begin with, rather than requiring people to hack on their CPPFLAGS? I don't offhand see much need for knowing the PG version at the Makefile level, but I do see the usefulness at the C-code level. I think Joe Conway is already doing something like this for pl/r ... leastwise he's shown bits of #ifdef'd code in past email. It would be interesting to see the details of his solution. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Module dependency on PostgeSQL version
Tom Lane wrote: Thomas Hallgren [EMAIL PROTECTED] writes: The PGSQL_MAJOR_VER and PGSQL_MINOR_VER does not exist today. Ideally, I'd like to find them in src/Makefile.global. Only thing present seems to be the VERSION. I'd like to see something like: PGSQL_MAJOR_VER := 7 PGSQL_MINOR_VER := 5 PGSQL_PATCH_VER := devel VERSION := $(PGSQL_MAJOR_VER).$(PGSQL_MINOR_VER).$(PGSQL_PATCH_VER) To be used in CPPFLAGS as: -DPGSQL_MAJOR_VER=$(PGSQL_MAJOR_VER) etc. Wouldn't it be better to just put those #defines in to begin with, rather than requiring people to hack on their CPPFLAGS? I don't offhand see much need for knowing the PG version at the Makefile level, but I do see the usefulness at the C-code level. I think Joe Conway is already doing something like this for pl/r ... leastwise he's shown bits of #ifdef'd code in past email. It would be interesting to see the details of his solution. regards, tom lane If the PostgreSQL source distribution had #defines residing in postgres.h or similar, that would certanly do the trick for me. Until they arrive I'll use the following (somewhat backward) solution to the problem. My makefile now contains the following and it seems to do the job: include $(PGSQLDIR)/src/Makefile.global # Substitute dot for whitespace so that we can pick # the individual parts later on with the $(word,...) # SS_VERSION := $(subst ., ,$(subst devel,.devel,$(VERSION))) # Pass major, minor, and patch to the preprocessor # override CPPFLAGS := \ -DPKGLIBDIR=\$(pkglibdir)\ -I$(INCLDIR) \ -DPGSQL_MAJOR_VER=$(word 1,$(SS_VERSION)) \ -DPGSQL_MINOR_VER=$(word 2,$(SS_VERSION)) \ -DPGSQL_PATCH_VER=$(word 3,$(SS_VERSION)) \ $(CPPFLAGS) The PGSQLDIR points to the PostgreSQL source distribution. The reason for the two level (subst...) command is that you currently use 7.5devel as the VERSION, i.e. no '.' between minor and patch. IMHO, 7.5.devel would be more consistent. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Module dependency on PostgeSQL version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
DBD::Pg uses pg_config --version and parses the output to set the
version information before compiling. It finds pg_config by using
PG envrironment variables, or looks in the path. Once running, it
does a SELECT version() to find out what server it is running
against. Whenever possible, is now uses the new protocol version
information. It's much handier to just say:
if (protocol=3) {
...
}
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200405112153
-BEGIN PGP SIGNATURE-
iD8DBQFAoYRyvJuQZxSWSsgRAj8oAJwP4AxEYsBwnbeo4Aw97JtCpUC4tACgo0P1
WMvC9yck8REb15E4uod56hA=
=C2GF
-END PGP SIGNATURE-
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Module dependency on PostgeSQL version
Tom Lane wrote: Thomas Hallgren [EMAIL PROTECTED] writes: PGSQL_MAJOR_VER := 7 PGSQL_MINOR_VER := 5 PGSQL_PATCH_VER := devel VERSION := $(PGSQL_MAJOR_VER).$(PGSQL_MINOR_VER).$(PGSQL_PATCH_VER) To be used in CPPFLAGS as: -DPGSQL_MAJOR_VER=$(PGSQL_MAJOR_VER) etc. Wouldn't it be better to just put those #defines in to begin with, rather than requiring people to hack on their CPPFLAGS? I don't offhand see much need for knowing the PG version at the Makefile level, but I do see the usefulness at the C-code level. I think Joe Conway is already doing something like this for pl/r ... leastwise he's shown bits of #ifdef'd code in past email. It would be interesting to see the details of his solution. This is what I currently have: #if (CATALOG_VERSION_NO = 200211021) #define PG_VERSION_73_COMPAT #elif (CATALOG_VERSION_NO = 200310211) #define PG_VERSION_74_COMPAT #else #define PG_VERSION_75_COMPAT #endif Since CATALOG_VERSION_NO doesn't change between major releases, it seems to work pretty well. Joe ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
