Adam Rich wrote:
> For me, saying all new fields must go at the end of the table is like
> saying all new functions must go at the end of your C source file.
> Not that it makes *any* difference to the end user, or other
> applications using your libraries, but as developers we tend to
> be more organized than the general public. Most programmers
> habitually organize their source code to keep related functions
> together. It seems sloppy to have 10 memory-related functions
> together in the source, and then an 11th hidden 6 pages down in the
> middle of file-related functions. And if you're writing OO code in
> C++ or Java, you even group private variables and methods separately
> from public ones. Most of the people who advocate tacking new fields
> at the end of a table would never dream of following this convention
> for source code.
>
otoh, reordering the fields in a table would likely require a global
exclusive access lock on the table for the duration of the operation,
which for a large table could be substantial. AFAIK, the current ALTER
TABLE ... ADD COLUMN just locks the table for updates, the pre-existing
fields can still be SELECTed until the ALTER completes and the new
columns become visible.