On Feb 10, 2011, at 7:05 PM, Tom Lane wrote: > I like this because (a) it's one less step, and one less concept for > users to deal with, and (b) it's much harder to screw up. If you forget > FROM OLD when you needed it, the CREATE will fail with "object already > exists" errors. If you use FROM OLD when you shouldn't have, it will > fail with "object doesn't exist" errors. There's no way for the command > to apparently succeed while not actually creating the desired state.
+1 > (I'm not wedded to the phrase "FROM OLD" in particular, but it does > reuse already existing keywords. Also, maybe it'd be better to reserve > a version string such as "old" or "bootstrap", so that the bootstrap > script could be called something more legible like foo-bootstrap-1.0.sql.) Well, it's not really a bootstrap, is it? FROM OLD is okay, though not great. FROM BEFORE would be better. Or IMPLICIT? (It was implicitly an extension before.) Or, hey, FROM NOTHING! :-) >> That reminds me (OT), it's currently impossible to write an uninstall script >> for a custom data type because of the circular dependency between a type and >> its I/O functions. There's no way around that sort of DROP EXTENSION >> CASCADE, is there? > > Yeah, DROP TYPE CASCADE is currently the accepted way to do that, and > it's definitely a tad risky in that you might zap more than just the > type and the I/O functions. But I don't feel a need to do anything > special to fix that, because grouping the type and the functions into > an extension will take care of the problem. You will not need to say > CASCADE unless you're actually wanting to delete objects outside the > extension. Fair enough. Thanks, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
