Re: RFD: schemas and different kinds of Postgres objects

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