Consider syntactic form when disambiguating function vs column reference.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 18 Jun 2018 15:39:33 +0000 (11:39 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 18 Jun 2018 15:39:33 +0000 (11:39 -0400)
commitb97a3465d73bfc2a9f5bcf5def1983dbaa0a26f8
tree729c396a8314c6db5219beeb8c385b11a5646f60
parent4c8156d87108fa1f245bee13775e76819cd46a90
Consider syntactic form when disambiguating function vs column reference.

Postgres has traditionally considered the syntactic forms f(x) and x.f
to be equivalent, allowing tricks such as writing a function and then
using it as though it were a computed-on-demand column.  However, our
behavior when both interpretations are feasible left something to be
desired: we always chose the column interpretation.  This could lead
to very surprising results, as in a recent bug report from Neil Conway.
It also created a dump-and-reload hazard, since what was a function
call in a dumped view could get interpreted as a column reference
at reload, if a matching column name had been added to the underlying
table since the view was created.

What seems better, in ambiguous situations, is to prefer the choice
matching the syntactic form of the reference.  This seems much less
astonishing in general, and it fixes the dump/reload hazard.

Although this could be called a bug fix, there have been few complaints
and there's some small risk of breaking applications that depend on the
old behavior, so no back-patch.  It does seem reasonable to slip it
into v11, though.

Discussion: https://postgr.es/m/CAOW5sYa3Wp7KozCuzjOdw6PiOYPi6D=VvRybtH2S=2C0SVmRmA@mail.gmail.com
doc/src/sgml/rowtypes.sgml
src/backend/parser/parse_func.c
src/test/regress/expected/rowtypes.out
src/test/regress/sql/rowtypes.sql