Re: Module dependency on PostgeSQL version

Поиск
Список
Период
Сортировка
От Thomas Hallgren
Тема Re: Module dependency on PostgeSQL version
Дата
Msg-id thhal-0im59AdmEClwobrZmWo1v9TR6r5ItVx@mailblocks.com
обсуждение исходный текст
Ответ на Module dependency on PostgeSQL version  (Thomas Hallgren <thhal@mailblocks.com>)
Ответы Re: Module dependency on PostgeSQL version
Список 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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Shachar Shemesh
Дата:
Сообщение: Re: Probably security hole in postgresql-7.4.1
Следующее
От: "Thomas Hallgren"
Дата:
Сообщение: Re: Module dependency on PostgeSQL version