Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
От | Tom Lane |
---|---|
Тема | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() |
Дата | |
Msg-id | 1742513.1688129204@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
|
Список | pgsql-bugs |
Andrew Dunstan <andrew@dunslane.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. regards, tom lane
В списке pgsql-bugs по дате отправления: