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



Tue, 11 May 2004 21:06:00 +0200
Thomas Hallgren <thhal@mailblocks.com>
Module dependency on PostgeSQL version
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

Tue, 11 May 2004 17:00:08 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Module dependency on PostgeSQL version 
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=$(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


Wed, 12 May 2004 00:16:20 +0200
Thomas Hallgren <thhal@mailblocks.com>
Re: 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 greg@turnstep.com
PGP Key: 0x14964AC8 200405112153
 
-----BEGIN PGP SIGNATURE-----
 
iD8DBQFAoYRyvJuQZxSWSsgRAj8oAJwP4AxEYsBwnbeo4Aw97JtCpUC4tACgo0P1
WMvC9yck8REb15E4uod56hA=
=C2GF
-----END PGP SIGNATURE-----



Wed, 12 May 2004 01:55:40 -0000
"Greg Sabino Mullane" <greg@turnstep.com>
Re: Module dependency on PostgeSQL version
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

Tue, 11 May 2004 21:27:41 -0700
Joe Conway <mail@joeconway.com>
Re: 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



Wed, 12 May 2004 09:41:56 +0200
"Thomas Hallgren" <thhal@mailblocks.com>
Re: Module dependency on PostgeSQL version

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


Wed, 12 May 2004 09:58:30 +0200
"Thomas Hallgren" <thhal@mailblocks.com>
Re: 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" <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

Wed, 12 May 2004 08:47:09 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Module dependency on PostgeSQL version 