Re: Happy column adding and dropping - Mailing list pgsql-hackers

From Ross J. Reedstrom
Subject Re: Happy column adding and dropping
Date
Msg-id 20000125142219.A1169@rice.edu
Whole thread Raw
In response to Re: Happy column adding (was RE: [HACKERS] Happy column dropping)  (Don Baccus <dhogaza@pacifier.com>)
Responses Re: Happy column adding and dropping
List pgsql-hackers
On Tue, Jan 25, 2000 at 11:20:01AM -0800, Don Baccus wrote:
> At 12:29 PM 1/25/00 -0600, Ross J. Reedstrom wrote:
> >On Tue, Jan 25, 2000 at 12:23:15PM -0500, Tom Lane wrote:
> 
> >> Well, yeah: wouldn't you expect that "ADD COLUMN x DEFAULT 42" would
> >> cause every row currently existing in the table to acquire x = 42,
> >> rather than x = NULL?  In fact that would *have* to happen to allow
> >> constraints to be added; consider ADD COLUMN x DEFAULT 42 NOT NULL.
> 
> >Actually, no I wouldn't expect it. That's mixing DDL and DML in one
> >statement.  I expect the ALTER command to be pure DDL, and the UPDATE
> >to be pure DML.
> 
> Hmmm...interesting...is alter table in the standard?  Again, my copy
> of Date's SQL 92 primer is somewhere 'wteen Boston, MA and Portland, OR,
> so I can't look myself.   Since you've got the standard available you
> can answer perhaps?

Gee, Don, that's a good idea, I should have thought of it myself! BTW,
what I have is labelled "Second Informal Review Draft" and is dated July
30, 1992.  I don't know how it differs from the final standard, if at all.
I orginally got it from someone on this list, I forget who. Anyone
want a copy, I'll happily email it to you, or throw it on a website:
it's 1.6M of ASCII, ready for the line printer ;-) (273K gzipped.)

That said, ALTER is in fact described, and the ADD COLUMN case agrees
with Tom's expectations, rather than mine, see General Rule 2, below:
   11.11  <add column definition>
   Function
   Add a column to a table.
   Format
   <add column definition> ::=        ADD [ COLUMN ] <column definition>

   Syntax Rules
      None.
   Access Rules

      None.
   General Rules
   1) The column defined by the <column definition> is added to T.
   2) Let C be the column added to T. Every value in C is the default      value for C.
      Note: The default value of a column is defined in Subclause 11.5,      "<default clause>".
      Note: The addition of a column to a table has no effect on any      existing <query expression> included in a
viewdescriptor or      <search condition> included in constraint descriptor because      any implicit <column
reference>sin these clauses are replaced      by explicit <column reference>s when the clause is originally
evaluated.See the Syntax Rules of Subclause 7.10, "<query ex-      pression>".
 


For what it's worth, here's what it says about DROP COLUMN. Note that
the question of what to do about references to columns: standard says,
throw and error, unless the DBA really means it, with the CASCADE option,
except for VIEWs, which get dropped, unless the DBA is careful to say
RESTRICT.

   11.15  <drop column definition>
   Function
   Destroy a column.
   Format
   <drop column definition> ::=        DROP [ COLUMN ] <column name> <drop behavior>
   <drop behavior> ::= CASCADE | RESTRICT
   Syntax Rules
   1) Let T be the table identified by the <table name> in the con-      taining <alter table statement> and let TN be
thename of T.
 
   2) Let C be the column identified by the <column name> CN.
   3) C shall be a column of T and C shall not be the only column of      T.
   4) If RESTRICT is specified, then C shall not be referenced in      the <query expression> of any view descriptor or
inthe <search      condition> of any constraint descriptor other than a table con-      straint descriptor that
containsreferences to no other column      and that is included in the table descriptor of T.
 
      Note: A <drop column definition> that does not specify CASCADE      will fail if there are any references to that
columnresulting      from the use of CORRESPONDING, NATURAL, SELECT * (except where      contained in an exists
predicate>),or REFERENCES without a      <reference column list> in its <referenced table and columns>.
 
      Note: If CASCADE is specified, then any such dependent object      will be dropped by the execution of the
<revokestatement> spec-      ified in the General Rules of this Subclause.
 
   Access Rules
      None.
   General Rules
   1) Let A be the current <authorization identifier>. The following      <revoke statement> is effectively executed
witha current <au-      thorization identifier> of "_SYSTEM" and without further Access      Rule checking:
 
        REVOKE INSERT(CN), UPDATE(CN), REFERENCES(CN) ON TABLE TN        FROM A CASCADE
   2) Let VN be the name of any view that contains a reference to      column C of table T. The following <drop view
statement>is      effectively executed with a current <authorization identifier>      of "_SYSTEM" and without further
AccessRule checking:
 
        DROP VIEW VN CASCADE
   3) If the column is not based on a domain, then its data type de-      scriptor is destroyed.
   4) The data associated with C is destroyed and the descriptor of C      is removed from the descriptor of T.
   5) The identified column and its descriptor are destroyed.
   6) The degree of T is reduced by 1. The ordinal position of all      columns having an ordinal position greater than
theordinal      position of C is reduced by 1.
 


pgsql-hackers by date:

Previous
From:
Date:
Subject: Re: Postgresql Perl Problem
Next
From: Bruce Momjian
Date:
Subject: Re: Happy column adding (was RE: [HACKERS] Happy column dropping)