Gregory Stark <stark@enterprisedb.com> writes:
> The other instance is in inv_api.c where it would be quite possible to use
> fastgetattr() instead. But the column is always at the same fixed offset and
> again it follows an int4 so it'll always be 4-byte aligned and work fine. So
> for performance reasons perhaps we should keep this as well?
After looking closer, I think there are worse problems here: the code is
still using VARSIZE/VARDATA etc, which it should not be because the
field could easily be in 1-byte-header form. And it seems like we
should be checking for NULL, too, because initdb only marks the first
two fields as NOT NULL. The latter would qualify as a security hole
except that you'd have to be superuser to put a record with a null data
field into pg_largeobject.
I concur that we probably want to avoid adding fastgetattr for
performance reasons, seeing that this table's layout seems unlikely
to change. But it seems like we might want to trouble with a null
test. Thoughts?
regards, tom lane