Re: ALTER EXTENSION UPGRADE, v3

________________________________________
From: pgsql-hackers-owner(at)postgresql(dot)org [pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tom Lane [tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Friday, February 11, 2011 7:35 PM
To: Dimitri Fontaine
Cc: David E. Wheeler; Robert Haas; Josh Berkus; pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

"We will add logic to find a chain of update scripts leading from oldv to
v, in case that exact combination is not available in the extension's
script directory. (NOTE: maybe in the CREATE ... FROM case, it would be
a better idea to not do that search, but insist on finding exactly
extname-oldv-v.sql? That would provide at least a little bit of extra
protection against wrong FROM choice. Not sure how much it helps
though.)

Version strings will have no hard-wired semantics except equality; we
don't need a sorting rule."

This has the side effect that you can also have downgrade scripts. I don't know if this is designed or just coincidental, so thought it would be worth mentioning. It can have some impact on how to find the update chain to the desired version (loops in the graph), although standard graph traversal algorithms should handle this just fine. The worst case is that if you are upgrading from 1.2 to 2.0 the path is 1.2 -> 1.1 -> 2.0, even if there exists a path 1.2 -> 1.8 -> 1.9 -> 2.0. This could potentially result in data loss, if the downgrade drops some columns or something like that.

All this can of course be avoided by documenting that even if it is possible to define downgrade script, don't do it...

- Anssi
PS. I hope this mail comes out somewhat sanely formatted, using our lovely OWA-webmail here...