Re: effective SELECT from child tables - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: effective SELECT from child tables
Date
Msg-id 20051002133045.GF30492@svana.org
Whole thread Raw
In response to Re: effective SELECT from child tables  (Hannu Krosing <hannu@skype.net>)
Responses Re: effective SELECT from child tables
Re: effective SELECT from child tables
List pgsql-hackers
On Sun, Oct 02, 2005 at 03:57:37PM +0300, Hannu Krosing wrote:
> On P, 2005-10-02 at 01:24 -0400, Greg Stark wrote:
> > Of course that only works if the reason they want to set fill the rows with
> > the default value isn't precisely because NULL is a perfectly reasonable thing
> > for the column to have (but not what they want for the existing rows).
>
> Sure.
>
> What would be needed for adding new colums with default filling would be
> some end-of-tuple marker or stored column count or tuple version nr, and
> then a rule (or just default behaviour) of showing default value for
> *missing* columns (colno > nr of stored columns).

Actually, PostgreSQL does know the number of columns in a tuple. It
would be possible get change heap_getattr to return the default value.

However, from a semantic point of view, it would be a bit strange. If
you added a column, updated some rows then set a default, that default
might end up applying to every row, except the ones you already
modified. With careful coding you may be able to get around this.

However, a good argument can be made that setting the DEFAULT for a
column shouldn't change data anywhere.  What about if I want to change
the default for new values but not for old ones. That wouldn't work if
the database starts adding values randomly, depending on when they are
read...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: effective SELECT from child tables
Next
From: Tom Lane
Date:
Subject: Re: 8.1beta2 pg_dumpall inconsistencies