Re: effective SELECT from child tables

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>

In response to

Responses

Browse pgsql-hackers by date

  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