On 02/07/2012 03:03 PM, Tom Lane wrote:
Andrew Dunstan<and...@dunslane.net> writes:
On 02/07/2012 12:47 PM, Tom Lane wrote:
In general I think we'd have to require that colnames be supplied in all
RowExprs if we go this way. Anyplace that's trying to slide by without
will have to be fixed. I don't recall how many places that is.
I just had a thought that maybe we could make this simpler by dummying
up a list of colnames if we don't have one, instead of that assertion.
Or am I on the wrong track.
Well, if there are more than one or two RowExpr creators for which a
dummy set of colnames is the best we can do anyway, that might be a
reasonable answer. But I think it would encourage people to be lazy
and let the dummy colnames be used even when they can do better, so
I'd rather not take this as a first-choice solution.
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()
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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
