Re: Selecting fields from a RowExpr

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Selecting fields from a RowExpr
Дата
Msg-id CAFj8pRA4_y9zsrV8jJN4Q+Deec2xKHS4=SzRR+1k1tGgvBG1Tw@mail.gmail.com
обсуждение исходный текст
Ответ на Selecting fields from a RowExpr  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi

ne 27. 10. 2019 v 19:47 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
At pgconf.eu, someone whose name I've forgotten pointed out to me
that this doesn't work:

regression=# select (row(1, 2.0)).f1;
ERROR:  could not identify column "f1" in record data type
LINE 1: select (row(1, 2.0)).f1;
                ^

The fields of an anonymous rowtype are certainly named f1, f2, etc,
so it seems like this *should* work.  A related case is

regression=# select (row(1, 2.0)).*;
ERROR:  record type has not been registered

Admittedly, these probably aren't terribly useful cases in practice,
but it's unfortunate that they don't work as one would expect.
So I propose the attached patch to make them work.

The underlying reason for both of these failures is that RowExpr
doesn't carry a typmod, so if it's of type RECORD then
get_expr_result_type doesn't know how to find a tupdesc for it.
The minimum-code solution is to teach get_expr_result_type to build
a tupdesc directly from the RowExpr, and that seems to be necessary
for complicated cases like

select (r).f1 from (select row(1, 2.0) as r) ss;

In an earlier version of the patch I chose to add in some fast-path
logic in ParseComplexProjection and ExpandRowReference, so as to
make the really simple cases shown above a bit less inefficient.
But on second thought, these are such corner cases that it doesn't
seem worth carrying extra code for them.  The cases that are more
likely to arise in practice are like that last example, and we
can't optimize that in the parser.  (The planner will optimize
FieldSelect-from-RowExpr after flattening subqueries, which is
probably as much as we really need to do here.)

I don't feel a need to back-patch this, but I would like to push
it into HEAD.

some times I hit this limit, an can be nice more consistent behave of composite types.

It's new feature - and there is not a reason for back-patching

Regards

Pavel

Thoughts?

                        regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Selecting fields from a RowExpr
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock(PG10.7)