Re: row_to_json(), NULL values, and AS
От | Neil Conway |
---|---|
Тема | Re: row_to_json(), NULL values, and AS |
Дата | |
Msg-id | CAOW5sYY2bkRutaoTm1CG5VoYhZk6YvL1m8MkUONJvXmtfkFH_g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: row_to_json(), NULL values, and AS (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: row_to_json(), NULL values, and AS
|
Список | pgsql-bugs |
[ Hi Tom! Hope you're doing well. ] On Fri, Jun 15, 2018 at 7:53 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. Interesting! Your proposed change seems quite reasonable to me. Thanks for digging into it. Neil
В списке pgsql-bugs по дате отправления: