Re: Module dependency on PostgeSQL version

From: "Thomas Hallgren" <thhal(at)mailblocks(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joe Conway" <mail(at)joeconway(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Module dependency on PostgeSQL version
Date: 2004-05-12 07:41:56
Message-ID: thhal-0im59AdmEClwobrZmWo1v9TR6r5ItVx@mailblocks.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> This is what I currently have:
>
> #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
>
> Since CATALOG_VERSION_NO doesn't change between major releases, it seems
> to work pretty well.
>
> Joe
>
Ok, thanks for the tip. Somewhat cleaner than what I suggested.

Your solution doesn't cover the situations when you have dependencies on
patch versions though, does it? There's no way to distinguish between 7.4.1
and 7.4.2 if the catalog version doesn't change. Such situations will arise.
A module author finds a bug in the backend, reports it, and creates a less
than perfekt work-around in his own code. At some point the bug gets
properly fixed and included in some patch release. Using that release, the
work-around is obsolete.

I had an example when this happened a while back (concerning loss of
MemoryContext between function ivocations). My workaround was really ugly
(using the parent MemoryContext) and could potentially waste a lot of memory
so it was imperative to actually get rid of it as soon as the patch was
released.

regards,

Thomas Hallgren

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shachar Shemesh 2004-05-12 07:46:00 Re: Probably security hole in postgresql-7.4.1
Previous Message Simon Riggs 2004-05-12 07:23:20 Re: XLog: how to log?