using SysCacheGetAttrNotNull in place of heap_getattr

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: using SysCacheGetAttrNotNull in place of heap_getattr
Date: 2023-08-23 14:43:42
Message-ID: 20230823144342.s5rduk2hsfsc6d2x@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I was about to push a quick patch to replace the use of heap_getattr()
in get_primary_key_attnos() with SysCacheGetAttrNotNull(), because that
makes the code a few lines shorter and AFAICS there's no downside.
However, I realized that the commit that added the function
(d435f15fff3c) did not make any such change at all -- it only changed
SysCacheGetAttr calls to use the new function, but no heap_getattr.
And we don't seem to have added such calls after.

Essentially the possibly contentious point is that the tuple we'd be
deforming did not come from syscache, but from a systable scan, so
calling a syscache function on it could be seen as breaking some API.
(Of course, this only works if there is a syscache on the given

But we do have precedent: for example RelationGetFKeyList uses a sysscan
to feed DeconstructFkConstraintRow(), which extracts several attributes
that way using the CONSTROID syscache.

Does anybody think this could be a problem, if we extended it to be more
widely used?

Álvaro Herrera Breisgau, Deutschland —
"Los cuentos de hadas no dan al niño su primera idea sobre los monstruos.
Lo que le dan es su primera idea de la posible derrota del monstruo."
(G. K. Chesterton)


Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-08-23 14:54:30 Re: [PATCH] Add function to_oct
Previous Message Heikki Linnakangas 2023-08-23 14:40:32 Re: Unlogged relations and WAL-logging