From: | Don Baccus <dhogaza(at)pacifier(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Happy column adding (was RE: [HACKERS] Happy column dropping) |
Date: | 2000-01-25 23:10:22 |
Message-ID: | 3.0.1.32.20000125151022.00f8c4c0@mail.pacifier.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 06:01 PM 1/25/00 -0500, Tom Lane wrote:
>Don Baccus <dhogaza(at)pacifier(dot)com> writes:
>>> In particular, if parsetrees for stored rules and constraints worked
>>> that way, renumbering attributes that follow the added/dropped column
>>> would become a lot less painful.
>
>> Yes...I see what you're driving at. Very interesting idea. The stored
>> rules and constraints would in this case would still refer to the remaining
>> columns after a drop, right?
>
>Right. You'd still need to scan through all the rules/constraints to
>look for references to a column-to-be-dropped (and then either drop that
>rule/constraint or kick out an error, as appropriate). But you wouldn't
>have to *change* any surviving rules/constraints, because they'd still
>be referring to the same permanent IDs of the remaining columns.
Good, I understand then.
>Also, inherited ADD COLUMN would become far easier, because it wouldn't
>change the rules/constraints of child tables at all --- even though the
>new column would change the logical numbering of child-table columns,
>it wouldn't change their permanent IDs and thus we wouldn't have to
>update rules/constraints.
Ahhh...yes. I haven't looked at the inheritance code, yet, but I see
what you're saying. I think. Do child-table columns follow parent-table
columns by some chance (in today's absolute column number scheme)?
>If we were willing to hardwire the assumption that DROP COLUMN never
>physically drops a column, but only hides it and adjusts logical column
>numbers, then the physical column numbers could serve as permanent IDs;
>so we'd only need two numbers not three. This might be good, or not.
Yes. But if I'm right about how child-table columns are numbered,
wouldn't add column still cause a problem, i.e. you'd still have to
change their physical column number?
I'm probably misunderstanding here because I've not looked at the
inheritance mechanism at all. Maybe I'll do that for a little evening
entertainment.
- 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 | Peter Eisentraut | 2000-01-25 23:15:35 | Column ADDing issues |
Previous Message | Tom Lane | 2000-01-25 23:01:36 | Re: Happy column adding (was RE: [HACKERS] Happy column dropping) |