Обсуждение: how solve diff of API counstruct_md_array between 8.1 and 8.2?
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. Thank you Pavel Stehule _________________________________________________________________ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/
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/ > 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.
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/ > 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.