Re: When do we lose column names?

On 02/09/2012 03:06 PM, Andrew Dunstan wrote:
>
>
> On 02/09/2012 02:54 PM, Tom Lane wrote:
>> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>>> OK, the one place that needs to be fixed to avoid the crash caused by
>>> the json regression tests with the original patch is in
>>> src/backend/parser/parse_expr.c:transformRowExpr().
>>> Other candidates I have found that don't set colnames and should
>>> probably use dummy names are:
>>> * src/backend/parser/gram.y (row: production)
>>> *
>>> src/backend/optimizer/prep/prepunion.c:adjust_appendrel_attrs_mutator()
>>> * src/backend/optimizer/util/var.c:flatten_join_alias_vars_mutator()
>> Hm, can't the last two get real column names from somewhere?
>
> Possibly. I'll dig a bit deeper.
>

I've had a look at these two. It's at least not obvious to me how to do
this simply, if at all. In the last case it looks like we'd need to
process the object recursively just like we do to extract the field
values, and I don't know where to get them in the appendrel case at all,
possibly because I'm not very familiar with this code.

Do we actually need to bother with these cases? The regression tests
pass without touching them, either because they don't matter or because
we don't have a test for these cases that would tickle the assertion
that was failing. If they don't matter, would it not be better just to
note that in the code rather than building a list of field names for no
good purpose?

cheers

andrew