Re: contrib function naming, and upgrade issues - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: contrib function naming, and upgrade issues
Date
Msg-id 3A33AAA6-22AD-432D-AEA9-6CDEB5E15960@hi-media.com
Whole thread Raw
In response to Re: contrib function naming, and upgrade issues  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Le 23 mars 09 à 20:33, Robert Haas a écrit :
> It may well be that the table has data in it that was inserted after
> module creation time, and the user may want it preserved with the
> upgrade, but there's really no way to even begin to guess what the
> user had in mind here.

Exactly, we're not in the business of second guessing our users. So we
have versioning information built into the facility, and we should
provide a way to tell from which version we're upgrading if that's the
case.

Then the module author's would be able to do things depending on the
value of the OLD.version (to reuse existing notations and concepts) or
something. That means supporting conditionals, and that's sound like
it's not in the TODO for the first implementation. But still, I don't
see how you manage to give the modules authors a nice upgrade facility
without something like this.

Regards,
--
dim




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: contrib function naming, and upgrade issues
Next
From: Bruce Momjian
Date:
Subject: Unsupported effective_io_concurrency platforms