Hi,
On 2019-03-25 12:45:36 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-03-25 12:33:38 -0400, Tom Lane wrote:
> >> I don't think it's wise to think of these things as just "slots";
> >> that name is way too generic. They are "tuple slots", and so that
> >> word has to stay in the relevant function names.
>
> > Hm. But we already have slot_{getsomeattrs, getallattrs, attisnull,
> > getattr, getsysattr}. But perhaps the att in there is enough addiitional
> > information?
>
> I don't claim to be entirely innocent in this matter ;-)
>
> If we're going to rename stuff in this area without concern for avoiding
> inessential code churn, then those are valid targets as well.
FWIW, I don't have much of a problem with current slot_ names.
> BTW, maybe it's worth drawing a naming distinction between
> slot-type-specific and slot-type-independent functions?
> (I assume there are still some of the latter.)
Hm, I guess that depends on what you classify as type independent. Is
something like slot_getattr type independent, even though it internally
calls slot_getsomeattrs, which'll call a callback if additional
deforming is necessary?
I'd say, if you exclude functions like that, ExecStoreVirtualTuple(),
ExecStoreAllNullTuple(), slot_getmissingattrs(), ExecSetSlotDescriptor()
are probably the only ones that have no awareness of the type of a
slot.
I'm not sure it matters that much however? Unless you store something in
a slot, code normally shouldn't have to care what type a slot is.
Greetings,
Andres Freund