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?
(Itwas 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
circulardependency 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
