Re: Schemas vs. PostQUEL: resolving qualified identifiers

> PostQUEL-isms that no longer work:
>
> table.col.func Must rewrite as func(table.col)
>
> table.func1.func2 Must rewrite as, eg, func2(func1(table.*))
>
> While there are a couple of examples of the above two constructs in the
> regression tests, I doubt they are used much in the real world.

Imho OK. I only need table.func1 .

> Another PostQUEL-ism that I would like to remove is col(tab) to mean
> tab.col; I'd prefer to restrict the function syntax to functions only.
> We could continue to support this for unqualified table names, but
> given the above rules it could not work for a qualified table name,
> eg, col(schema.tab) would be misinterpreted. Again, it seems unlikely
> that many people are using this, so we may as well try to regularize
> the syntax as much as we can.

Sounds ok too. Imho very hard to grok syntax anyway.

What I do not like at all is the notion that "table" == "table".* .
(IIRC there has already been some discussion where I objected to that.)

"table" as function parameter imho passes an object of type "table"
to the function. This involves type checking, and that the function only
has one argument.

"table".* to the contrary is not an object, but one object (one parameter)
per table column. This is imho easier to understand, since select table.*
also does it like that. Thus calling func(table.*) should imho rather be
mapped to func (table.col1, table.col2 ...).

Also remember that the standard now has room for nested types.
create table atab (
x int,
y int );

( We use create table, standard iirc uses "create type".)

create table btab (
position atab,
info text );

How would you map btab.* here ? (x, y, info) ? Imho no.
Imho it should map to (atab, info) thus you need the
notion of passing an object anyway.

Andreas