| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Hannu Krosing <hannu(at)skype(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-04 03:24:30 |
| Message-ID: | 87irwe7ymp.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)skype(dot)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.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2005-10-04 03:31:21 | Re: [HACKERS] External Sort timing debug statements |
| Previous Message | Greg Stark | 2005-10-04 03:22:31 | Re: effective SELECT from child tables |