Andrew Dunstan <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
