Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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  

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.


In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group