Re: RFD: schemas and different kinds of Postgres objects

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Bill Studenmund <wrstuden(at)netbsd(dot)org>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: RFD: schemas and different kinds of Postgres objects
Date: 2002-01-25 05:40:18
Message-ID: 23721.1011937218@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-01-25 05:55:32 Re: RFD: schemas and different kinds of Postgres objects
Previous Message Lau NH 2002-01-25 05:39:14 Database access right