Re: effective SELECT from child tables - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: effective SELECT from child tables
Date
Msg-id 1128371733.5882.9.camel@fuji.krosing.net
Whole thread Raw
In response to Re: effective SELECT from child tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: effective SELECT from child tables  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
On P, 2005-10-02 at 23:00 -0400, Tom Lane wrote:
> Greg Stark <gsstark@mit.edu> writes:
> > It would be nice to be able to do:
> >   ALTER TABLE ADD foo integer DEFAULT 1
> > And there's no question of what what the semantics of this are.
> 
> Sure, but you can only optimize this if the default expression is
> immutable...
> 
> > On the other hand if you do
> >  ALTER TABLE ADD foo integer
> > and then later do
> >  ALTER TABLE ALTER foo SET DEFAULT 1
> > then there is a window where all those foos are NULL and then they magically
> > become 1? That doesn't seem tenable.
> 
> It'd also be contrary to the SQL spec, AFAICS.
> 
> Here's another interesting case to think about:
> 
>     ALTER TABLE ADD foo integer DEFAULT 1
>     ...
>     ALTER TABLE ALTER foo SET DEFAULT 2
>
> You'll have to pay the table-traversal cost on one step or the other.

The second, ALTER ... SET DEFAULT, would only set default for newly
inserted columns, not the ones which are missing due to tuples being
created before the column existed.

But completely different syntax may be more clear.

ALTER TABLE ADD foo integer WITH DEFAULT 1;

Or whatever 

-- 
Hannu Krosing <hannu@skype.net>



pgsql-hackers by date:

Previous
From: "Jeffrey W. Baker"
Date:
Subject: Re: [PERFORM] A Better External Sort?
Next
From: Josh Berkus
Date:
Subject: Re: [PERFORM] A Better External Sort?