Re: When do we lose column names?

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?  Also, why
would it be the responsibility of the grammar production to fill in the
list, rather than transformRowExpr?

> Given a function:
>     extern List *makeDummyColnames(List * args);
> what's the best place to put it? I couldn't see a terribly obvious place 
> in the source.

If there are enough potential users to justify having such a global
function at all, then we might as well not bother but just let execQual
fill in dummy names on the fly.  Providing such a function means that
there is nothing whatever pushing writers of new RowExpr constructors to
not be lazy --- the path of least resistance will be to call
makeDummyColnames.  I was hoping that there would be few enough places
where no information is available that we'd not need to have a global
function like that.

			regards, tom lane