To: Peter Eisentraut <peter_e@gmx.net>
cc: Bill Studenmund <wrstuden@netbsd.org>, pgsql-hackers@postgreSQL.org
Subject: Re: RFD: schemas and different kinds of Postgres objects 
In-reply-to: <Pine.LNX.4.30.0201250013040.686-100000@peter.localdomain> 
References: <Pine.LNX.4.30.0201250013040.686-100000@peter.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
	message dated "Fri, 25 Jan 2002 00:27:07 -0500"
Date: Fri, 25 Jan 2002 00:40:18 -0500
Message-ID: <23721.1011937218@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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