database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Consider syntactic form when disambiguating function vs column reference.

Browse Source 
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
This commit is contained in:
Tom Lane
2018-06-18 11:39:33 -04:00
parent 4c8156d871
commit b97a3465d7
4 changed files with 148 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
doc/src/sgml/rowtypes.sgml
View File

@ -441,9 +441,12 @@ SELECT c.somefunc FROM inventory_item c;
Because of this behavior, it's unwise to give a function that takes a
single composite-type argument the same name as any of the fields of
that composite type. If there is ambiguity, the field-name
interpretation will be preferred, so that such a function could not be
called without tricks. One way to force the function interpretation is
to schema-qualify the function name, that is, write
interpretation will be chosen if field-name syntax is used, while the
function will be chosen if function-call syntax is used. However,
<productname>PostgreSQL</productname> versions before 11 always chose the
field-name interpretation, unless the syntax of the call required it to
be a function call. One way to force the function interpretation in
older versions is to schema-qualify the function name, that is, write
<literal><replaceable>schema</replaceable>.<replaceable>func</replaceable>(<replaceable>compositevalue</replaceable>)</literal>.
</para>
</tip>