Re: Two aesthetic bugs in the 1-byte packed varlena code - Mailing list pgsql-patches

From Tom Lane
Subject Re: Two aesthetic bugs in the 1-byte packed varlena code
Date
Msg-id 15788.1181668489@sss.pgh.pa.us
Whole thread Raw
In response to Two aesthetic bugs in the 1-byte packed varlena code  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Two aesthetic bugs in the 1-byte packed varlena code
List pgsql-patches
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

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Two aesthetic bugs in the 1-byte packed varlena code
Next
From: Greg Smith
Date:
Subject: Re: trace_checkpoint parameter patch