Re: When do we lose column names?

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