Re: effective SELECT from child tables

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

In response to

Browse pgsql-hackers by date

  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