Re: Extensions, patch v18 (merge against master, bitrot-only-fixes)

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: Extensions, patch v18 (merge against master, bitrot-only-fixes)
Дата
Msg-id m2d3p1o47h.fsf@2ndQuadrant.fr
обсуждение исходный текст
Ответ на Re: Extensions, patch v18 (merge against master, bitrot-only-fixes)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Extensions, patch v18 (merge against master, bitrot-only-fixes)  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> However, the only way I can see to fix this "automatically" is to have
> the makefiles propagate PG_VERSION_NUM (or one of the other values set
> by configure) into generated control files.

Ah, somewhat like what I was asked to remove from the patch, right?

-EXTVERSION = $(VERSION)

>  I don't think that's what
> we want either.  If we do that, then people are going to be forced to
> go through an ALTER EXTENSION UPGRADE cycle whether or not anything
> actually changed in the extension's SQL definitions.  We really only
> want the extension's SQL version to change when there was a meaningful
> change in the SQL commands.

Well that's just a facility, and very useful for people that have a Make
variable where the extension's version is already held. This problem of
having a VERSION that moves when the extension possibly didn't change
seems pretty specific to PostgreSQL, not typical for extensions authors.

> I'm not sure that I see a better answer than hand-maintained version
> numbers in each extension SQL file.  But if that's where we're going,
> they should be in the SQL files, not in either the Makefiles or control
> files.

You lost me. Are you wanting extension authors to maintain meta data in
the SQL script, with some new syntax support, or maybe from calling a
function? How do you think this will play with upgrading?

That doesn't sound any simpler to me. The whole goal of the control file
is to be able to register the extension in the catalog and get an OID
there to manage the dependencies (so that we get a single command per
extension in pg_dump output). The first design proposed an SQL command
to fill in the catalog, but that command must be separate from what the
DBA will have to type in to have the server execute the script, so this
idea has been beaten by the control file idea (thanks goes to Heikki).

Now, we could go with the current patch for starters and add some
facilities around 9.2 when we have experienced the maintenance
burden. And extension authors will probably be asking for some more
facilities too, by then.


Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] V3: Idle in transaction cancellation
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: directory archive format for pg_dump