Rules for accessing tuple data in backend code

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Rules for accessing tuple data in backend code
Дата
Msg-id Pine.LNX.4.30.0201281638310.688-100000@peter.localdomain
обсуждение исходный текст
Ответы Re: Rules for accessing tuple data in backend code  (John Gray <jgray@azuli.co.uk>)
Re: Rules for accessing tuple data in backend code  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
I'm sort of confused about the ways in which you can access tuple data you
get from heap scans or syscache lookups.  Perhaps this can be cleared up
and documented, because new contributors might like this information.
Here's the information and questions I have:

Tuples obtained from heap scans (heap_getnext, etc.) can always be
dissected with heap_getattr().

Tuples obtained from syscache lookups (SearchSysCache) can always be
dissected with SysCacheGetAttr().

What happens when I try heap_getattr() on a syscache tuple?

Tuples obtained from heap scans or syscache lookups may be dissected via
GETSTRUCT if and only if the attribute and all attributes prior to it are
fixed-length and non-nullable.

(Probably there should be cases about explicit index scans here, but I
haven't done those and they should be rare.)

The question I'm particularly struggling with is, when does TOASTing and
de-TOASTing happen?  And if it doesn't, what's the official way to do it?
I've found PG_DETOAST_DATUM and PG_DETOAST_DATUM_COPY.  Why would I want a
copy?  (How can detoasting happen without copying?)  And if I want a copy,
in what memory context does it live?  And can I just pfree() the copy if I
don't want it any longer?

-- 
Peter Eisentraut   peter_e@gmx.net



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Per-database and per-user GUC settings
Следующее
От: John Gray
Дата:
Сообщение: Re: Rules for accessing tuple data in backend code