From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Rod Taylor <pg(at)rbt(dot)ca> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hannu Krosing <hannu(at)skype(dot)net> |
Subject: | Re: effective SELECT from child tables |
Date: | 2005-10-04 04:12:24 |
Message-ID: | 877jct9azb.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Rod Taylor <pg(at)rbt(dot)ca> writes:
> > 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;
This inserts a physical "1" in the record (the "current" default").
> ALTER TABLE tab ALTER foo SET DEFAULT 2
> INSERT INTO tab DEFAULT VALUES;
This inserts a physical "2" in the record.
> ALTER TABLE tab ALTER foo SET DEFAULT 3
> INSERT INTO tab DEFAULT VALUES;
This inserts a physical "3" in the record.
> SELECT foo FROM tab;
This checks for any old records that predate the column and use the "initial"
default of 1 for those records. The three records above all postdate the
column addition so they have values present, namely 1, 2, and 3.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-10-04 04:21:28 | Re: Tuning current tuplesort external sort code for 8.2 |
Previous Message | Rod Taylor | 2005-10-04 04:06:15 | Re: effective SELECT from child tables |