major, minor and micro version
Hello,
is it possible to get the PG version splitted up into major, minor and
micro version in the future?
For now, only PG_VERSION is defined (at least, what i can see) and it is
not possible to use PG_VERSION at compile time to determine the actual
PG version.
Example:
In a module i want to use some of the new features from 8.0, but if the
user is compiling the module in a 7.x source tree, the old (but slower)
functions must be used (SPI_exec versus SPI_execute).
kind regards
--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)
On Wed, Jun 22, 2005 at 12:36:23AM +0200, Andreas 'ads' Scherbaum wrote:
Hello,
is it possible to get the PG version splitted up into major, minor and
micro version in the future?
For now, only PG_VERSION is defined (at least, what i can see) and it is
not possible to use PG_VERSION at compile time to determine the actual
PG version.Example:
In a module i want to use some of the new features from 8.0, but if the
user is compiling the module in a 7.x source tree, the old (but slower)
functions must be used (SPI_exec versus SPI_execute).
This has been requested before, and while I don't remember whether the
petition has been accepted, I do remember that the customary workaround
was to use the CATALOG_VERSION_NO symbol from src/include/catversion.h.
This number is supposed to keep unchanged across a "major.minor"
release.
--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"When the proper man does nothing (wu-wei),
his thought is felt ten thousand miles." (Lao Tse)