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

From Rod Taylor
Subject Re: effective SELECT from child tables
Date
Msg-id 1128397904.6543.151.camel@home
Whole thread Raw
In response to Re: effective SELECT from child tables  (Greg Stark <gsstark@mit.edu>)
Responses Re: effective SELECT from child tables
Re: effective SELECT from child tables
List pgsql-hackers
On Mon, 2005-10-03 at 23:24 -0400, Greg Stark wrote:
> Hannu Krosing <hannu@skype.net> writes:
> 
> > On P, 2005-10-02 at 23:00 -0400, Tom Lane wrote:
> > > 
> > > 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.
> 
> Hm. So you're saying there are only ever exactly two types of defaults. The
> "initial" default that applies to all tuples that were created before the
> column was added. And the "current" default that only ever applies to newly
> created tuples.
> 
> That does seem to cleanly close this hole.

I don't think so.

ALTER TABLE tab ADD foo integer DEFAULT 1;
INSERT INTO tab DEFAULT VALUES;

ALTER TABLE tab ALTER foo SET DEFAULT 2
INSERT INTO tab DEFAULT VALUES;

ALTER TABLE tab ALTER foo SET DEFAULT 3
INSERT INTO tab DEFAULT VALUES;

SELECT foo FROM tab;
-- 



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] External Sort timing debug statements
Next
From: Rod Taylor
Date:
Subject: Re: effective SELECT from child tables