Peter Eisentraut <peter_e@gmx.net> writes:
> Here's a tricky question: In what situations is a.b valid to mean b(a)?
I defined that in my first message on these issues: the last element
of a dotted-name string can be either a field name or a function
(which is applied to a table that's the next-to-last item). The
next-to-last element is always a table name.
> Because in a general object-like system you could write a.b.c.d to mean
> d(c(b(a))).
Indeed, that can happen now in Postgres, and as I pointed out we have
to get rid of it. That doesn't mean we need to eliminate the base case,
however.
> Somehow we need to do at least one of three things:
> 1. Require parentheses after function calls.
Breaks existing code unnecessarily.
> 2. Use a different operator to invoke function calls (SQL uses ->).
Breaks existing code unnecessarily.
> 3. Require users to register functions as "methods" with the data type
> before being able to say a.b for b(a). This also takes care of having to
> specify the schema of b because that's declared when you define the
> method.
Doesn't buy you anything unless you intend to reject function
overloading too. With overloading you may have multiple functions
b(something), so you still have to be able to determine what a is
without any context.
regards, tom lane