Re: Selecting fields from a RowExpr

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
>
>