Re: checking my understanding of TupleDesc

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: checking my understanding of TupleDesc
Дата
Msg-id 28712.1573598360@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: checking my understanding of TupleDesc  (Chapman Flack <chap@anastigmatix.net>)
Ответы Re: checking my understanding of TupleDesc
Список pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> On 09/29/19 20:13, Chapman Flack wrote:
>> From looking around the code, I've made these tentative observations
>> about TupleDescs:
>> 
>> 1. If the TupleDesc was obtained straight from the relcache for some
>> relation, then all of its attributes should have nonzero attrelid
>> identifying that relation, but in (every? nearly every?) other case,
>> the attributes found in a TupleDesc will have a dummy attrelid of zero.

I'm not sure about every vs. nearly every, but otherwise this seems
accurate.  Generally attrelid is meaningful in a pg_attribute catalog
entry, but not in TupleDescs in memory.  It appears valid in relcache
entry tupdescs only because they are built straight from pg_attribute.

>> 2. The attributes in a TupleDesc will (always?) have consecutive attnum
>> corresponding to their positions in the TupleDesc (and therefore
>> redundant).

Correct.

> And one more:

>   3. One could encounter a TupleDesc with one or more 'attisdropped'
>      attributes, which do have their original attnums (corresponding
>      to their positions in the TupleDesc and therefore redundant),
>      so the attnums of nondropped attributes may be discontiguous.

Right.

>      Is it simple to say under what circumstances a TupleDesc possibly
>      with dropped members could be encountered,

Any tupdesc that's describing the rowtype of a table with dropped columns
would look like that.

>      and under what other
>      circumstances one would only encounter 'cleaned up' TupleDescs with
>      no dropped attributes, and contiguous numbers for the real ones?

I don't believe we ever include dropped columns in a projection result,
so generally speaking, the output of a query plan node wouldn't have them.

There's a semi-exception, which is that the planner might decide that we
can skip a projection step for the output of a table scan node, in which
case dropped columns would be included in its output.  But that would only
be true if there are upper plan nodes that are doing some projections of
their own.  The final query output will definitely not have them.

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: make pg_attribute_noreturn() work for msvc?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: make pg_attribute_noreturn() work for msvc?