how solve diff of API counstruct_md_array between 8.1 and 8.2?

On Thu, Feb 16, 2006 at 08:36:34PM +0100, Pavel Stehule wrote:

Hello

I use counstruct_md_array function in my Orafunc module. CVS version has
diff def now. I am findig way for simple solution of maintaince source code
for both version. I have PG_VERSION variable, but it's unusable. Is there
way for contrib's autors differentiate PostgreSQL versions? I don't want to
have two versions of source code.

For my stuff I've generally use CATALOG_VERSION_NO. It's not very easy,
but by looking through CVS you can find when the function was created
and in your code use:

#ifdef CATALOG_VERSION_NO > yyyymmddN
/* New stuff */
#else
/* Old stuff */
#endif

Hope this helps,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Martijn van Oosterhout wrote:

On Thu, Feb 16, 2006 at 08:36:34PM +0100, Pavel Stehule wrote:

I use counstruct_md_array function in my Orafunc module. CVS version has
diff def now. I am findig way for simple solution of maintaince source code
for both version. I have PG_VERSION variable, but it's unusable. Is there
way for contrib's autors differentiate PostgreSQL versions? I don't want to
have two versions of source code.

For my stuff I've generally use CATALOG_VERSION_NO. It's not very easy,
but by looking through CVS you can find when the function was created
and in your code use:

#ifdef CATALOG_VERSION_NO > yyyymmddN
/* New stuff */
#else
/* Old stuff */
#endif

I do pretty much the same thing in PL/R. The good news is that
CATALOG_VERSION_NO doesn't change for each major release once it is
released. The following hasn't been updated since the 8.1 release, but
you could use it as a starting point:

#if (CATALOG_VERSION_NO <= 200211021)
#define PG_VERSION_73_COMPAT
#elif (CATALOG_VERSION_NO <= 200310211)
#define PG_VERSION_74_COMPAT
#elif (CATALOG_VERSION_NO <= 200411041)
#define PG_VERSION_80_COMPAT
#else
#define PG_VERSION_81_COMPAT
#endif

HTH,

Joe

Joe Conway wrote:

Martijn van Oosterhout wrote:

On Thu, Feb 16, 2006 at 08:36:34PM +0100, Pavel Stehule wrote:

I use counstruct_md_array function in my Orafunc module. CVS version has
diff def now. I am findig way for simple solution of maintaince source code
for both version. I have PG_VERSION variable, but it's unusable. Is there
way for contrib's autors differentiate PostgreSQL versions? I don't want to
have two versions of source code.

For my stuff I've generally use CATALOG_VERSION_NO. It's not very easy,
but by looking through CVS you can find when the function was created
and in your code use:

#ifdef CATALOG_VERSION_NO > yyyymmddN
/* New stuff */
#else
/* Old stuff */
#endif

I do pretty much the same thing in PL/R. The good news is that
CATALOG_VERSION_NO doesn't change for each major release once it is
released. The following hasn't been updated since the 8.1 release, but
you could use it as a starting point:

#if (CATALOG_VERSION_NO <= 200211021)
#define PG_VERSION_73_COMPAT
#elif (CATALOG_VERSION_NO <= 200310211)
#define PG_VERSION_74_COMPAT
#elif (CATALOG_VERSION_NO <= 200411041)
#define PG_VERSION_80_COMPAT
#else
#define PG_VERSION_81_COMPAT
#endif

Yea, that is probably the best you can do currently, but it is pretty
ugly. We have PQserverVersion() in libpq for use by clients, which
does:

conn->sversion = (100 * vmaj + vmin) * 100 + vrev;

Perhaps we should have a function in the server that has this.
PG_VERSION isn't easy to use because it is a string, and changes during
minor versions.

initdb.c uses get_short_version() to trims PG_VERSION to the major part.

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

On Fri, Feb 24, 2006 at 02:57:19PM -0500, Bruce Momjian wrote:

Yea, that is probably the best you can do currently, but it is pretty
ugly. We have PQserverVersion() in libpq for use by clients, which
does:

conn->sversion = (100 * vmaj + vmin) * 100 + vrev;

Perhaps we should have a function in the server that has this.
PG_VERSION isn't easy to use because it is a string, and changes during
minor versions.

We don't need a function to do it, because none of that can be used by
a compiler. If a structure gains or loses a member, the only way you
can do it portibly is if the compiler can determine which version to
use. The only thing the preprocessor can use is:

- Is a (preprocessor) symbol defined
- Is it numerically greater equal or less than another number

So the only solution would be something like:

#define POSTGRESQL_MAJOR 8
#define POSTGRESQL_MINOR 1
#define POSTGRESQL_RELEASE 1

Or

#define POSTGRESQL_VERSION 80101

Maybe something to indicate beta or CVS. Anything else is not likely to
be an improvement on what we have now. Besides, adding stuff now is not
terribly useful since people want to support back to 7.3/7.4 and until
a new scheme is old enough that 8.2 is ancient (first release it could
possibly appear in) it won't get a lot of usage.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

I have developed a patch which creates a new pg_config.h define called
PG_VERSION_NUM, which is a number like 80200, with no beta/devel
designation. I think this will be helpful (eventually) for people
writing plug-ins. Attached.

---------------------------------------------------------------------------

Martijn van Oosterhout wrote:
-- Start of PGP signed section.

On Fri, Feb 24, 2006 at 02:57:19PM -0500, Bruce Momjian wrote:

Yea, that is probably the best you can do currently, but it is pretty
ugly. We have PQserverVersion() in libpq for use by clients, which
does:

conn->sversion = (100 * vmaj + vmin) * 100 + vrev;

Perhaps we should have a function in the server that has this.
PG_VERSION isn't easy to use because it is a string, and changes during
minor versions.

We don't need a function to do it, because none of that can be used by
a compiler. If a structure gains or loses a member, the only way you
can do it portibly is if the compiler can determine which version to
use. The only thing the preprocessor can use is:

- Is a (preprocessor) symbol defined
- Is it numerically greater equal or less than another number

So the only solution would be something like:

#define POSTGRESQL_MAJOR 8
#define POSTGRESQL_MINOR 1
#define POSTGRESQL_RELEASE 1

Or

#define POSTGRESQL_VERSION 80101

Maybe something to indicate beta or CVS. Anything else is not likely to
be an improvement on what we have now. Besides, adding stuff now is not
terribly useful since people want to support back to 7.3/7.4 and until
a new scheme is old enough that 8.2 is ancient (first release it could
possibly appear in) it won't get a lot of usage.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.

-- End of PGP section, PGP failed!

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

On Tue, Feb 28, 2006 at 12:45:18AM -0500, Bruce Momjian wrote:

I have developed a patch which creates a new pg_config.h define called
PG_VERSION_NUM, which is a number like 80200, with no beta/devel
designation. I think this will be helpful (eventually) for people
writing plug-ins. Attached.

I like it. Arguably the development period between 8.1 and 8.2 could be
designated 80190 (8.1.90) with various betas being 80191-80199. But
hey, having any symbol define the current version is better than
nothing at all.

Thanks for this,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Martijn van Oosterhout wrote:
-- Start of PGP signed section.

On Tue, Feb 28, 2006 at 12:45:18AM -0500, Bruce Momjian wrote:

I have developed a patch which creates a new pg_config.h define called
PG_VERSION_NUM, which is a number like 80200, with no beta/devel
designation. I think this will be helpful (eventually) for people
writing plug-ins. Attached.

I like it. Arguably the development period between 8.1 and 8.2 could be
designated 80190 (8.1.90) with various betas being 80191-80199. But
hey, having any symbol define the current version is better than
nothing at all.

Thanks for this,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.

OK, updated version of the patch attached and applied.

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

Martijn van Oosterhout wrote:
-- Start of PGP signed section.

On Tue, Feb 28, 2006 at 12:45:18AM -0500, Bruce Momjian wrote:

I have developed a patch which creates a new pg_config.h define
called PG_VERSION_NUM, which is a number like 80200, with no
beta/devel designation. I think this will be helpful
(eventually) for people writing plug-ins. Attached.

I like it. Arguably the development period between 8.1 and 8.2
could be designated 80190 (8.1.90) with various betas being
80191-80199. But hey, having any symbol define the current version
is better than nothing at all.

Thanks for this,
--
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/

Patent. n. Genius is 5% inspiration and 95% perspiration. A
patent is a tool for doing 5% of the work and then sitting around
waiting for someone else to do the other 95% so you can sue them.

OK, updated version of the patch attached and applied.

I still object to this. What is wrong with using the catalog version
number?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Bruce Momjian wrote:

Martijn van Oosterhout wrote:
-- Start of PGP signed section.

On Tue, Feb 28, 2006 at 12:45:18AM -0500, Bruce Momjian wrote:

I have developed a patch which creates a new pg_config.h define
called PG_VERSION_NUM, which is a number like 80200, with no
beta/devel designation. I think this will be helpful
(eventually) for people writing plug-ins. Attached.

I like it. Arguably the development period between 8.1 and 8.2
could be designated 80190 (8.1.90) with various betas being
80191-80199. But hey, having any symbol define the current version
is better than nothing at all.

Thanks for this,
--
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/

Patent. n. Genius is 5% inspiration and 95% perspiration. A
patent is a tool for doing 5% of the work and then sitting around
waiting for someone else to do the other 95% so you can sue them.

OK, updated version of the patch attached and applied.

I still object to this. What is wrong with using the catalog version
number?

It is pretty obscure to use a date stamp like that, rather than a number
just like PQserverVersion(). Also, it gives minor version information
that the catalog version does not.

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian wrote:

OK, updated version of the patch attached and applied.

I still object to this. What is wrong with using the catalog version
number?

It's partially redundant, but only partially, and I agree that it'll
probably be easier for people to use than the catversion number.

The case where it's not redundant would be if an add-on needs to deal
with an internal API change made in a sub-release, e.g. 8.1.4, where
the catversion number is not going to change. We've certainly done that
before and will do so again, when there's no other way to fix a bug.

regards, tom lane

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian wrote:

OK, updated version of the patch attached and applied.

I still object to this. What is wrong with using the catalog version
number?

It's partially redundant, but only partially, and I agree that it'll
probably be easier for people to use than the catversion number.

The case where it's not redundant would be if an add-on needs to deal
with an internal API change made in a sub-release, e.g. 8.1.4, where
the catversion number is not going to change. We've certainly done that
before and will do so again, when there's no other way to fix a bug.

Also, that macro block where Joe Conway compared catalog version numbers
and defined understandable macro names cried out for a solution.

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

It's partially redundant, but only partially, and I agree that it'll
probably be easier for people to use than the catversion number.

Also, that macro block where Joe Conway compared catalog version numbers
and defined understandable macro names cried out for a solution.

It's worth pointing out here that catversion was only intended to be
useful within a development cycle, ie, to prevent developers from
wasting time chasing pseudo-bugs that were really due to mismatch of
their newly compiled backend executable with not-so-new system catalog
contents. We never intended any code to depend on its specific value,
else we'd have used a definition with more mnemonic content than a
date-stamp.

regards, tom lane