Re: how solve diff of API counstruct_md_array between

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: how solve diff of API counstruct_md_array between
Date: 2006-02-24 20:14:07
Message-ID: 20060224201407.GD9390@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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(at)svana(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2006-02-24 22:00:26 Re: Blog post on EnterpriseDB...maybe off topic
Previous Message Bruce Momjian 2006-02-24 19:57:19 Re: how solve diff of API counstruct_md_array between

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-02-25 02:28:30 Re: pg_service.conf
Previous Message Bruce Momjian 2006-02-24 20:00:54 Re: memset using long instead of int32