Thread: Module dependency on PostgeSQL version
I'd like to make a small suggestion that would enable external modules to manage dependencies to PostgreSQL versions. Consider the following code: #if PGSQL_MAJOR_VER > 7 || (PGSQL_MAJOR_VER == 7 && PGSQL_MINOR_VER > 4) result = HeapTupleGetDatum(tuple); #else /* PostgreSQL 7.4 or earlier */ TupleTableSlot* slot = TupleDescGetSlot(tupleDesc); result = TupleGetDatum(slot,tuple); #endif 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. The alternative for me (and others who undoubtedly will encounter the same problem) is to invent something ugly to split the current VERSION variable. Considering ease of extension of PostgreSQL, I wanted to suggest this first. Kind regards, Thomas Hallgren
Thomas Hallgren <thhal@mailblocks.com> 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
Tom Lane wrote: > Thomas Hallgren <thhal@mailblocks.com> 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=$(word2,$(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
-----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 greg@turnstep.com
PGP Key: 0x14964AC8 200405112153
-----BEGIN PGP SIGNATURE-----
iD8DBQFAoYRyvJuQZxSWSsgRAj8oAJwP4AxEYsBwnbeo4Aw97JtCpUC4tACgo0P1
WMvC9yck8REb15E4uod56hA=
=C2GF
-----END PGP SIGNATURE-----
Tom Lane wrote: > Thomas Hallgren <thhal@mailblocks.com> 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
> 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
""Greg Sabino Mullane"" <greg@turnstep.com> 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
> 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" <thhal@mailblocks.com> 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