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
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 |