Version defines
Greets,
Would it be possible to get something along the lines of the attached
patch in 8? (major,minor,patch,state version defines)
(I tried making them shell vars and giving it to AC_INIT, but it seemed
to want a literal, so...)
Yes, I know there are other ways to get and define this information, but
[something like] this is considerably more convenient, IMO.
--
Regards,
James William Pye
Attachments:
versions.patchtext/x-patch; charset=UTF-8; name=versions.patchDownload
Index: configure.in
===================================================================
RCS file: /projects/cvsroot/pgsql/configure.in,v
retrieving revision 1.383
diff -c -r1.383 configure.in
*** configure.in 25 Oct 2004 00:11:04 -0000 1.383
--- configure.in 29 Oct 2004 18:21:13 -0000
***************
*** 26,31 ****
--- 26,35 ----
AC_PREFIX_DEFAULT(/usr/local/pgsql)
AC_SUBST(configure_args, [$ac_configure_args])
+ AC_DEFINE_UNQUOTED(PG_VERSION_MAJOR, 8, [PostgreSQL major version])
+ AC_DEFINE_UNQUOTED(PG_VERSION_MINOR, 0, [PostgreSQL minor version])
+ AC_DEFINE_UNQUOTED(PG_VERSION_PATCH, 0, [PostgreSQL patch level])
+ AC_DEFINE_UNQUOTED(PG_VERSION_STATE, "beta4", [PostgreSQL version state])
AC_DEFINE_UNQUOTED(PG_VERSION, "$PACKAGE_VERSION", [PostgreSQL version])
AC_CANONICAL_HOST
Index: src/include/pg_config.h.in
===================================================================
RCS file: /projects/cvsroot/pgsql/src/include/pg_config.h.in,v
retrieving revision 1.80
diff -c -r1.80 pg_config.h.in
*** src/include/pg_config.h.in 6 Oct 2004 09:35:22 -0000 1.80
--- src/include/pg_config.h.in 29 Oct 2004 18:21:13 -0000
***************
*** 587,592 ****
--- 587,604 ----
/* Define to the address where bug reports for this package should be sent. */
#undef PACKAGE_BUGREPORT
+ /* Define to the major version */
+ #undef PG_VERSION_MAJOR
+
+ /* Define to the minor version */
+ #undef PG_VERSION_MINOR
+
+ /* Define to the patch level */
+ #undef PG_VERSION_PATCH
+
+ /* Define to version descriptor */
+ #undef PG_VERSION_STATE
+
/* Define to the full name of this package. */
#undef PACKAGE_NAME
James William Pye <flaw@rhid.com> writes:
Would it be possible to get something along the lines of the attached
patch in 8? (major,minor,patch,state version defines)
This has been proposed and rejected before, mainly on the grounds that
it would encourage bad programming practices.
At compile time, you should be checking the specific feature you care
about, not a system version number (this is pretty much the entire point
behind Autoconf). At run time, you need to be making a run-time test
anyway; compiling against version x.y headers does not guarantee
anything about what version you will be executing against at runtime.
regards, tom lane
On Sun, 2004-10-31 at 08:02, Tom Lane wrote:
This has been proposed and rejected before, mainly on the grounds that
it would encourage bad programming practices.
I admit that I am probably practicing this bad programming at few places
in my source, and shame on me for it. I have hoped to tighten it up a
bit later, but it is convenient for the time being.
At compile time, you should be checking the specific feature you care
about,
Well, for one of my uses, it is not a feature check. My PL loads a
Python extension module whose path is dependent on the major and minor
version of the PostgreSQL installation that the PL was compiled against.
So I construct the module path string based on the major and minor at
compile time.
If this is the stance that the group has, that is fine. For now, I will
continue my shameful practice of parsing up pg_config --version and
defining the components for use in my source. (;
--
Regards,
James William Pye
James William Pye <flaw@rhid.com> writes:
At compile time, you should be checking the specific feature you care
about,
Well, for one of my uses, it is not a feature check. My PL loads a
Python extension module whose path is dependent on the major and minor
version of the PostgreSQL installation that the PL was compiled against.
So I construct the module path string based on the major and minor at
compile time.
Er ... can't you just keep it in pkglibdir and refer to it via $libdir?
Given that 8.0 now supports relocatable installations, I'd think it best
to avoid hardwiring any paths at compile time.
regards, tom lane
James William Pye wrote:
If this is the stance that the group has, that is fine. For now, I will
continue my shameful practice of parsing up pg_config --version and
defining the components for use in my source. (;
FWIW, here's what I've been using in PL/R for a while now:
/* working with postgres 7.3 compatible sources */
#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
Joe
On Sun, 2004-10-31 at 10:49, Tom Lane wrote:
Er ... can't you just keep it in pkglibdir and refer to it via $libdir?
Given that 8.0 now supports relocatable installations, I'd think it best
to avoid hardwiring any paths at compile time.
Hmm..
I think it would be best to keep Python [extension] modules in Python's
site-packages.
AFA hardwiring is concerned, I will probably make it a GUC variable in
8.0 that will default to how I currently hardwire it.
--
Regards,
James William Pye