Re: R: Field's position in Table - Mailing list pgsql-general

From John R Pierce
Subject Re: R: Field's position in Table
Date
Msg-id 4A92F855.3090204@hogranch.com
Whole thread Raw
In response to Re: R: Field's position in Table  (Adam Rich <adam.r@sbcglobal.net>)
Responses Re: R: Field's position in Table
List pgsql-general
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.



pgsql-general by date:

Previous
From: Sergey Samokhin
Date:
Subject: Re: How to simulate crashes of PostgreSQL?
Next
From: Sergey Samokhin
Date:
Subject: Re: What approach should I use instead of creating tables on the fly?