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.
-- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
