From: | Don Baccus <dhogaza(at)pacifier(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "PostgreSQL Development" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Happy column dropping |
Date: | 2000-01-25 02:41:37 |
Message-ID: | 3.0.1.32.20000124184137.01069490@mail.pacifier.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 09:12 PM 1/24/00 -0500, Tom Lane wrote:
> * VACUUM with rebuild or ADD/DROP COLUMN: write new data into
> files with an incremented version number.
Just a reality check for my learning of the internals. Out of curiousity
I coincidently have spent the last hour looking to see how add column's
implemented. It doesn't appear to do anything other than the new attribute
to the proper system table. heap_getattr() just returns null if you ask
for an attribute past the end of the tuple.
This would appear to be (at least one reason) why you can't add a "not null"
constraint to a column you're adding to an existing relation, or set the
new column to some non-null default value.
Correct? (again, to see if my eyeballs and brain are working in synch
tonight)
Does your comment imply that it's planned to change this, i.e. actually
add the new column to each tuple in the relation rather than use the
existing, somewhat elegant hack?
Just curious...
- 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-01-25 02:48:46 | Re: [HACKERS] Happy column dropping |
Previous Message | Chris Bitmead | 2000-01-25 02:41:25 | Re: [HACKERS] DISTINCT ON: speak now or forever hold your peace |