RE: Happy column adding (was RE: [HACKERS] Happy column dropping)

> -----Original Message-----
> From: hannu(at)hu(dot)tm(dot)ee [mailto:hannu(at)hu(dot)tm(dot)ee]On Behalf Of Hannu Krosing
>
> Hiroshi Inoue wrote:
> >
> > > However, heap_getattr still won't see the default since it simply
> > > checks to see of the attribute number falls off the end of the
> > > tuple and then returns null.
> > >
> >
> > Sorry,the following question might be already answered but too
> > many postings for me.
> >
> > Do we have to refer default value for already inserted rows ?
> > Doesn't 'default' have its meaning only when rows are about to be
> > inserted ?
>

Oh,I found it from Ross's posting.

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>"

Is this reasonable ?
.
> I think the case was about adding a NOT NULL column and setting
> current NULL
> columns to DEFAULT seemed like a natural thing to do.
>
> But, considering the fact that DEFAULT can be something reaaly
> complex, like
> function that does a lot of things, it may be better to have the
> constraints
> checked at the end of transaction, like
>
> BEGIN;
> ALTER TABLE T1 ADD COLUMN C1 TEXT NOT NULL;

Isn't 'iNITIALLY DEFERRED' needed ?
ALTER TABLE T1 ADD COLUMN C1 TEXT NOT NULL INITIALLY DEFERRED;

> UPDATE T1 SET C1='MYDEFAULTVALUE';
> COMMIT;
>

It seems more reasonable than standard.
But is it worth breaking SQL standard ?

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp