Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()

On 2023-06-30 Fr 08:46, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>> On 2023-06-29 Th 18:41, Tom Lane wrote:
>>> Why not make the hash key be the value
>>> itself? Wrap it in a bytea perhaps to avoid needing a bespoke
>>> hash function.
>> Not sure I understand.
> Say the missingval for a particular column is text 'abc'.
> We don't actually care which column it is, all we need is a
> copy of that datum that will stay put for the rest of the
> transaction. So I'm thinking that the lookup key for the
> hash table should actually be the contents of the datum,
> and we don't need to store anything else at all. (If we
> happen to have two columns with the same missingval, they
> can perfectly well share this hash entry.) Then there's
> no question of invalidation, or at least the existing
> invalidation mechanisms for tupdescs do all we need.
>
>

OK, I get it. Do we have a routine to wrap a Datum in a bytea, or do I
need to write one? It's slightly amusing that the original patch for
fast defaults stored the missing value as a bytea, but someone (Andres
IIRC) preferred that we store it as a one element array, so that's what
we went with.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com