-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, Apr 26, 2008 at 6:33 AM, Tom Dunstan wrote:
> One scenario I'm not happy about is this: the friendly db admin has
> happily added an extra value to the end before and the operation has
> been a snap - no rewriting required. But this time either a) oid
> wraparound has occurred, b) she's inserted one or c) she's reordered
> them. Bam - we start rewriting the entire database.
As long as the documentation is candid about this, I don't think it's
a show-stopper. e.g.:
N.B. Rearranging an ENUM will usually be a simple operation, but
in $CERTAIN_CASES may require a rewrite of tables using the ENUM,
which is time consuming and locks the table against writing ...
You'd probably also want a "NOTICE: Change to ENUM will require
rewriting of tables." to be emitted when this happens.
>
> I've already suggested some alternatives in the reply to Brendan that
> would solve some of this, but I suppose another gross-seeming way to
> stop surprise rewrites would be to never do one unless given a FORCE
> REWRITE clause on the ALTER statement or something like that, and fail
> if a rewrite is required not specified.
>
That would be okay too, but I think I'd prefer proceeding with the
rewrite after emitting a NOTICE. If the db admin decides not to go
ahead, or wait to do it after hours, she can always hit ^C, right?
Cheers,
BJ
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: http://getfiregpg.org
iD8DBQFIEkO+5YBsbHkuyV0RAttIAJ9TNhNDN8SAsfyAR5MY9lppPyeWSQCfYOSs
kG25F0V44QqTZ4HMAWXL5JI=
=tG5q
-----END PGP SIGNATURE-----
