Re: contrib function naming, and upgrade issues

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
Subject: Re: contrib function naming, and upgrade issues
Date: 2009-03-23 20:11:49
Message-ID: 3A33AAA6-22AD-432D-AEA9-6CDEB5E15960@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-03-23 20:21:21 Unsupported effective_io_concurrency platforms
Previous Message Robert Haas 2009-03-23 19:33:00 Re: contrib function naming, and upgrade issues