Re: When do we lose column names?
От | Andrew Dunstan |
---|---|
Тема | Re: When do we lose column names? |
Дата | |
Msg-id | 4F3420B3.8050302@dunslane.net обсуждение исходный текст |
Ответ на | Re: When do we lose column names? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: When do we lose column names?
Re: When do we lose column names? |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: