At 01:49 PM 1/25/00 -0500, Tom Lane wrote:
>It occurs to me that in at least some of the places where attribute
>numbers are currently used, we ought to use *neither* logical nor
>physical column position, but rather a permanent unique ID --- the
>attribute tuple's OID would work, if it's assigned soon enough to be
>used for constraints given in CREATE TABLE. (Otherwise we could assign
>"column serial numbers" that count from 1 for each relation, but are
>never changed or recycled within the relation.)
>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?
As far as moving from phsyical to logical attribute numbering, and
the long slog involved, it might be possible to work towards this
goal in background mode by providing two sets of access macros/functions
with the same semantics, and as folks have time to slowly work through the
code. This wouldn't break anything. Nor would it substitute for
an intense push to finish the job before switching to such a scheme,
and of course there would be many errors.
It might slowly lower the barrier towards switching, though. The cost
would be a confusing and incomplete separation during the transition
period.
Of course, moving along this path would be something to consider only
if it were decided that eventually such a switch will be made. And I'm
not at all sure I like it.
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.