On 02/07/2012 03:03 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@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