Hi ne 27. 10. 2019 v 19:47 odesÃlatel Tom Lane <t...@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 > >
