From: | Hannu Krosing <hannu(at)skype(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: effective SELECT from child tables |
Date: | 2005-10-03 20:35:33 |
Message-ID: | 1128371733.5882.9.camel@fuji.krosing.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On P, 2005-10-02 at 23:00 -0400, Tom Lane wrote:
> Greg Stark <gsstark(at)mit(dot)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(at)skype(dot)net>
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2005-10-03 20:40:29 | Re: [HACKERS] A Better External Sort? |
Previous Message | Simon Riggs | 2005-10-03 20:35:30 | Tuning current tuplesort external sort code for 8.2 |