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 по дате отправления: