Re: Happy column adding (was RE: [HACKERS] Happy column dropping)

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Happy column adding (was RE: [HACKERS] Happy column dropping)
Date: 2000-01-25 16:01:25
Message-ID: 3.0.1.32.20000125080125.00f7f160@mail.pacifier.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 11:55 AM 1/25/00 +0100, Peter Eisentraut wrote:
>On Tue, 25 Jan 2000, Hiroshi Inoue wrote:
>
>> Even default is not allowed in ADD COLUMN now.
>> There may be other reasons why they aren't allowed.
>
>It's not a matter of *allowed*, it's a parsing deficiency. The fact that
>there was a default declared gets silently ignored. If y'all allow ;) I
>would like to fix that (have already started a bit) by perusing the code
>in parse_func.c:transformCreateStmt and do the same for the alter table
>add column part. Maybe and add/drop constraint will come out in the end as
>well.

However, heap_getattr still won't see the default since it simply
checks to see of the attribute number falls off the end of the
tuple and then returns null.

There's no provision for then pulling out the default value and
returning it instead.

I think this is why Tom was implying that add column should really
alter the table?

A fully-featured "add column" feature would be very nice, indeed.

- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2000-01-25 16:06:22 RE: Happy column adding (was RE: [HACKERS] Happy column dropping)
Previous Message Ken J. Wright 2000-01-25 15:55:05 Re: [INTERFACES] Re: ODBC drive strange behavior