"Bort, Paul" <pbort@tmwsystems.com> writes:
> Tom Lane said:
>> As long as the code using it never tries to access any
>> of the missing fields (t_xmin through t_ctid), this would work exactly
>> like a normal HeapTuple.
> This sounds like a security risk.
No more than any other wild-pointer problem. At the level of C code
it's always trivial to break anything ;-). The reason we don't need
to worry is that in the upper levels of the executor there is no such
thing as access to system columns --- any attempt to fetch a system
column is converted to a Var reference that appears in the initial
table-scan node, and thereafter it's an ordinary user column. This
must be so because trying to keep the system columns in their normal
privileged positions breaks down as soon as you consider a join; there
would only be room for one, and the query might well be trying to fetch
(say) ctid from more than one table. So any code that was trying to
fetch these fields would be buggy anyway.
In the case of the TupleHashTable code, the only access that need be
provided is through a TupleTableSlot. We could get a little bit of
protection against programming mistakes by using the "virtual tuple"
feature of slots to disallow attempts to fetch any system columns from
a truncated tuple. I'm not sure if this would be feasible for tuplesort
though; haven't looked at how it's used yet.
regards, tom lane
