I took a quick glance at this.

It boils down to essentially an:

1) ALTER TABLE .. ADD COLUMN <column> DEFAULT <default> <constraints>
2) UPDATE .. SET <column> = <default> IF <default> IS NOT NULL;
3) Add <constraints> including NOT NULL, CHECK, Foreign Key, etc. each
of which will do it's own confirmation pass on the values inserted into
the table by step 2 for the table for the new column.

If all additional constraints are added after the values are in the
table (via standard ALTER TABLE functions), is there anything the update
(step 2) needs to check aside from Domain constraints (coerce <default>
to datatype of <column>)?

For the update I intend to use double space, as if the user did those
items as individual commands within the same transaction.  Someone can
make it more efficient in regards to constraint checks, etc. in the
future if they want -- I don't intend to.

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
19 Jun 2003 02:09:42 +0000
Rod Taylor <rbt@rbt.ca>
add column .. default
Rod Taylor <rbt@rbt.ca> writes:
> For the update I intend to use double space, as if the user did those
> items as individual commands within the same transaction.

There is no alternative, unless you want the command to be
non-roll-back-able.

> Someone can
> make it more efficient in regards to constraint checks, etc. in the
> future if they want -- I don't intend to.

It'd be nice if you at least ensure that all the constraints are checked
in a single pass over the table (not one per constraint).  Right offhand
I do not see why they couldn't be checked in the same pass that does the
UPDATE.  For extra credit, detect that the default expression is
immutable or stable, and do the checks *once* not once per row.

			regards, tom lane

Wed, 18 Jun 2003 23:22:13 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: add column .. default 
> > Someone can
> > make it more efficient in regards to constraint checks, etc. in the
> > future if they want -- I don't intend to.
> 
> It'd be nice if you at least ensure that all the constraints are checked
> in a single pass over the table (not one per constraint).  Right offhand
> I do not see why they couldn't be checked in the same pass that does the
> UPDATE.  For extra credit, detect that the default expression is
> immutable or stable, and do the checks *once* not once per row.

I suppose that can be done.  It will take a significant reorganization
of the ALTER TABLE functions (or lots of duplicated code), but shouldn't
be that time consuming.

Anyway, I suppose you have indirectly confirmed that user triggers, etc.
should NOT fire on for the data update.  I didn't see anything in the
spec that said one way or the other.

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
19 Jun 2003 09:23:00 -0400
Rod Taylor <rbt@rbt.ca>
Re: add column .. default
Rod Taylor <rbt@rbt.ca> writes:
> Anyway, I suppose you have indirectly confirmed that user triggers, etc.
> should NOT fire on for the data update.  I didn't see anything in the
> spec that said one way or the other.

Actually, I didn't mean to take a position one way or the other.  You
could certainly argue that they should fire ...

			regards, tom lane

Thu, 19 Jun 2003 09:40:33 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: add column .. default 
On Thu, 2003-06-19 at 09:40, Tom Lane wrote:
> Rod Taylor <rbt@rbt.ca> writes:
> > Anyway, I suppose you have indirectly confirmed that user triggers, etc.
> > should NOT fire on for the data update.  I didn't see anything in the
> > spec that said one way or the other.
> 
> Actually, I didn't mean to take a position one way or the other.  You
> could certainly argue that they should fire ...

Do we want them to?  If we don't mind them being executed, it is far
easier to:

- alter table structure
- Add all new constraints (without confirming their correctness at that
time)
- update table contents via an SPI call to UPDATE WHERE <column> IS NULL

The where clause would avoid issues with inherited data being
overwritten when the child tables are updated.

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
19 Jun 2003 09:52:14 -0400
Rod Taylor <rbt@rbt.ca>
Re: add column .. default
Rod Taylor writes:

> Anyway, I suppose you have indirectly confirmed that user triggers, etc.
> should NOT fire on for the data update.  I didn't see anything in the
> spec that said one way or the other.

The spec doesn't say that they fire, so that means that they don't fire.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 19 Jun 2003 16:03:13 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: add column .. default
On Thu, Jun 19, 2003 at 09:52:14AM -0400, Rod Taylor wrote:
> On Thu, 2003-06-19 at 09:40, Tom Lane wrote:

> Do we want them to?  If we don't mind them being executed, it is far
> easier to:
> 
> - alter table structure
> - Add all new constraints (without confirming their correctness at that
> time)
> - update table contents via an SPI call to UPDATE WHERE <column> IS NULL

Sorry, I haven't read the spec, but what happens when there is a default
value already and it's not NULL?  Are tuples where column = default
updated?  Are tuples where column IS NULL updated?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Y dijo Dios: "Que sea Satanï¿½s, para que la gente no me culpe de todo a mï¿½."
"Y que hayan abogados, para que la gente no culpe de todo a Satanï¿½s"

Thu, 19 Jun 2003 10:05:27 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: add column .. default
Rod Taylor <rbt@rbt.ca> writes:
> - alter table structure
> - Add all new constraints (without confirming their correctness at that
> time)
> - update table contents via an SPI call to UPDATE WHERE <column> IS NULL

> The where clause would avoid issues with inherited data being
> overwritten when the child tables are updated.

But it creates issues with failing to check the new constraints at those
same child rows.

			regards, tom lane

Thu, 19 Jun 2003 10:12:49 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: add column .. default 
On Thu, 2003-06-19 at 10:05, Alvaro Herrera wrote:
> On Thu, Jun 19, 2003 at 09:52:14AM -0400, Rod Taylor wrote:
> > On Thu, 2003-06-19 at 09:40, Tom Lane wrote:
> 
> > Do we want them to?  If we don't mind them being executed, it is far
> > easier to:
> > 
> > - alter table structure
> > - Add all new constraints (without confirming their correctness at that
> > time)
> > - update table contents via an SPI call to UPDATE WHERE <column> IS NULL
> 
> Sorry, I haven't read the spec, but what happens when there is a default
> value already and it's not NULL?  Are tuples where column = default
> updated?  Are tuples where column IS NULL updated?

We're talking about add column.  Since it's a new column, there will
never be a default and all entries are NULL in PostgreSQL.

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
19 Jun 2003 10:29:36 -0400
Rod Taylor <rbt@rbt.ca>
Re: add column .. default
> > Anyway, I suppose you have indirectly confirmed that user triggers, etc.
> > should NOT fire on for the data update.  I didn't see anything in the
> > spec that said one way or the other.
> 
> The spec doesn't say that they fire, so that means that they don't fire.

Sounds like a definitive answer to me.  I'll go that route then.

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
19 Jun 2003 10:30:30 -0400
Rod Taylor <rbt@rbt.ca>
Re: add column .. default
Rod Taylor <rbt@rbt.ca> writes:
> On Thu, 2003-06-19 at 10:05, Alvaro Herrera wrote:
>> Sorry, I haven't read the spec, but what happens when there is a default
>> value already and it's not NULL?  Are tuples where column =3D default
>> updated?  Are tuples where column IS NULL updated?

> We're talking about add column.  Since it's a new column, there will
> never be a default and all entries are NULL in PostgreSQL.

That's an overly simplistic analysis, given that the column may already
exist in child tables.  I am not sure that the behavior is fully
consistent even now in such cases, but we at least should make certain
it doesn't become less consistent.

			regards, tom lane

Thu, 19 Jun 2003 10:42:52 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: add column .. default 
On Thu, 2003-06-19 at 10:42, Tom Lane wrote:
> Rod Taylor <rbt@rbt.ca> writes:
> > On Thu, 2003-06-19 at 10:05, Alvaro Herrera wrote:
> >> Sorry, I haven't read the spec, but what happens when there is a default
> >> value already and it's not NULL?  Are tuples where column =3D default
> >> updated?  Are tuples where column IS NULL updated?
> 
> > We're talking about add column.  Since it's a new column, there will
> > never be a default and all entries are NULL in PostgreSQL.
> 
> That's an overly simplistic analysis, given that the column may already
> exist in child tables.  I am not sure that the behavior is fully
> consistent even now in such cases, but we at least should make certain
> it doesn't become less consistent.

Right now if the column exists in the child table, the add column is
rejected.  I assume that will remain.

It is consistent with the user providing a column that inherits a column
from a parent by the same name.

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
19 Jun 2003 10:53:36 -0400
Rod Taylor <rbt@rbt.ca>
Re: add column .. default
Rod Taylor <rbt@rbt.ca> writes:
> Right now if the column exists in the child table, the add column is
> rejected.  I assume that will remain.

Have you actually tried it?

regression=# create table p1 (f1 int);
CREATE TABLE
regression=# create table c1 (f2 int) inherits(p1);
CREATE TABLE
regression=# alter table p1 add column f2 int;
NOTICE:  ALTER TABLE: merging definition of column "f2" for child c1
ALTER TABLE
regression=#

			regards, tom lane

Thu, 19 Jun 2003 11:00:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: add column .. default 
On Thu, 2003-06-19 at 15:00, Tom Lane wrote:
> Rod Taylor <rbt@rbt.ca> writes:
> > Right now if the column exists in the child table, the add column is
> > rejected.  I assume that will remain.
> 
> Have you actually tried it?

I used different datatypes which, of course, was the wrong test.


When I update the values in t1 I need to ensure I only get data from t1
that has the new column NULL.

Constraints to be checked are still only the ones attached to the
altered table directly.  A constraint on t1 only will not affect data on
t2.

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
19 Jun 2003 15:41:07 +0000
Rod Taylor <rbt@rbt.ca>
Re: add column .. default
> There is no alternative, unless you want the command to be
> non-roll-back-able.

Well, you can do a cluster-type table duplication...

> > Someone can
> > make it more efficient in regards to constraint checks, etc. in the
> > future if they want -- I don't intend to.
> 
> It'd be nice if you at least ensure that all the constraints are checked
> in a single pass over the table (not one per constraint).  Right offhand
> I do not see why they couldn't be checked in the same pass that does the
> UPDATE.  For extra credit, detect that the default expression is
> immutable or stable, and do the checks *once* not once per row.

And check domain constraints...?

Chris


Fri, 20 Jun 2003 09:22:36 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: add column .. default 
On Thu, 2003-06-19 at 21:22, Christopher Kings-Lynne wrote:
> > There is no alternative, unless you want the command to be
> > non-roll-back-able.
> 
> Well, you can do a cluster-type table duplication...

Thats still double the disk space, although that has the nice side
effect of not requiring a vacuum.
-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
20 Jun 2003 09:16:47 -0400
Rod Taylor <rbt@rbt.ca>
Re: add column .. default
> Thats still double the disk space, although that has the nice side
> effect of not requiring a vacuum.

Also, a rollback after 99% of the updates have been done will waste no
diskspace...

Chris



Sat, 21 Jun 2003 13:02:43 +0800 (WST)
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: add column .. default