Gregory Stark <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate