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@dunslane.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