Andres Freund <andres@anarazel.de> writes:
> On 2021-04-21 15:10:09 -0400, Tom Lane wrote:
>> So now I'm thinking the right thing to be working on is banning access
>> to system columns via partition parent tables (other than tableoid,
>> which ought to work).
> And ctid, I assume? While I have some hope for generalizing the
> representation of tids at some point, I don't think it's realistic that
> we'd actually get rid of them anytime soon.
Hmm, I'd have thought that ctid would be very high on the list of
things we don't want to assume are the same for all AMs. Admittedly,
refactoring that is going to be a large pain in the rear, but ...
I see that it actually works right now because slot_getsysattr
special-cases both tableoid and ctid, but I have a hard time
believing that that's a long-term answer.
> One could even imagine partition root specific system columns...
Yeah. As I think about this, I recall a previous discussion where
we suggested that maybe partitioned tables could have a subset
of system columns, whereupon all their children would be required
to support (at least) those system columns. But that would have
to be user-controllable, so a lot of infrastructure would need to
be built for it. For the moment I'd be satisfied with a fixed
decision that only tableoid is treated that way.
> ISTM that the minimal changes needed would be to reorder sysattr.h to
> have TableOidAttributeNumber be -2 (and keep
> SelfItemPointerAttributeNumber as -1). And then slowly change all code
> to not reference FirstLowInvalidHeapAttributeNumber - which seems like a
> *substantial* amount of effort, due to all the shifting of AttrNumber by
> FirstLowInvalidHeapAttributeNumber to be able to represent system
> columns in bitmaps.
Getting rid of FirstLowInvalidHeapAttributeNumber seems like nearly
a nonstarter. I'd be more inclined to reduce it by one or two so
as to leave some daylight for AMs that want system columns different
from the usual set. I don't feel any urgency about renumbering the
existing columns --- the value of that vs. the risk of breaking
things doesn't seem like a great tradeoff.
regards, tom lane