Re: RFD: schemas and different kinds of Postgres objects

Tom Lane writes:

> There could be multiple valid interpretations. When you can't even
> figure out where to start, it's too squishy for me. Code complexity
> isn't really the issue here, it's whether a user can understand what's
> going on.

Here's a tricky question: In what situations is a.b valid to mean b(a)?
Because in a general object-like system you could write a.b.c.d to mean
d(c(b(a))). There you've got a system where it's really impossible to
tell anything. Maybe b() returns a table, so a.b.c.d could mean
subattribute d in column c in the table returned by b(a).

Somehow we need to do at least one of three things:
1. Require parentheses after function calls.
2. Use a different operator to invoke function calls (SQL uses ->).
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.

SQL99 does 2 and 3 (but not 1).

I say, forget Oracle. Oracle doesn't have all the extensibility
functionality that PostgreSQL has. Let's build a system that is
consistent, orthogonal, and easy to use for *our* users, and those that
want to convert will quickly see the value.

--
Peter Eisentraut peter_e(at)gmx(dot)net