Re: row_to_json(), NULL values, and AS
От | Tom Lane |
---|---|
Тема | Re: row_to_json(), NULL values, and AS |
Дата | |
Msg-id | 32582.1529074393@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: row_to_json(), NULL values, and AS (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: row_to_json(), NULL values, and AS
Re: row_to_json(), NULL values, and AS |
Список | pgsql-bugs |
I wrote: > Neil Conway <neil.conway@gmail.com> writes: >> The following behavior does not seem self-consistent to me: > Likewise. Oh! What is actually happening is (1) With no explicit alias, the column name of the sub-select's second output column is chosen to be "row_to_json". (2) That makes the outer query's notation row_to_json(x) ambiguous: it could be a function-syntax reference to the column x.row_to_json. (3) As it happens, the column interpretation is chosen when it's ambiguous (cf ParseComplexProjection). I'm a bit hesitant to muck with this behavior, given that it's stood for ~20 years. However, if we did want to touch it, maybe the right thing would be to give up the absolutist position that f(x) and x.f are exactly interchangeable. We could say instead that we prefer the function interpretation if function syntax is used, and the column interpretation if column syntax is used. I don't know how likely that is to break existing apps ... perhaps not very, but I wouldn't risk back-patching it in any case. regards, tom lane
В списке pgsql-bugs по дате отправления: