
> 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

Wed, 23 Jan 2002 10:29:10 +0100
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Schemas vs. PostQUEL: resolving qualified identifiers
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> 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 ...).

Okay, but then how will you refer unambiguously to the rowtype object?
If you write func(schema.tab) the system will misinterpret it as
func(tab.col) --- which, in the worst case, might fail to fail because
there actually is such a column.  We have to make some compromises here.
I'm not all that thrilled with foo.* for rowtype either, but you haven't
offered a workable alternative.

			regards, tom lane

Wed, 23 Jan 2002 10:06:19 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Schemas vs. PostQUEL: resolving qualified identifiers 
Tom Lane wrote:
> 
> "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> > 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 ...).
> 
> Okay, but then how will you refer unambiguously to the rowtype object?
> If you write func(schema.tab) the system will misinterpret it as
> func(tab.col) --- which, in the worst case, might fail to fail because
> there actually is such a column.  We have to make some compromises here.
> I'm not all that thrilled with foo.* for rowtype either, but you haven't
> offered a workable alternative.
> 

What about casting with the keyord ROW?

func(ROW table) 

always refers to the row-type of table "table" even if there is
a column called "table".


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Wed, 23 Jan 2002 13:12:37 -0500
Fernando Nasser <fnasser@redhat.com>
Re: Schemas vs. PostQUEL: resolving qualified identifiers
Fernando Nasser <fnasser@redhat.com> writes:
> Tom Lane wrote:
>> Okay, but then how will you refer unambiguously to the rowtype object?

> What about casting with the keyord ROW?
> func(ROW table) 
> always refers to the row-type of table "table" even if there is
> a column called "table".

Strikes me as gratuituously different from the way everything else is
done.  We have .* and %ROWTYPE and so forth, and they're all suffixes.
The closest analogy to your ROW syntax is CAST, but it doesn't alter the
initial interpretation of its argument.

I was toying with the notion of inventing some new notation like
	table.**
I don't like double-asterisk much, but maybe there's some other symbol
we could use here?

			regards, tom lane

Wed, 23 Jan 2002 14:00:00 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Schemas vs. PostQUEL: resolving qualified identifiers 
Tom Lane wrote:
> 
> Fernando Nasser <fnasser@redhat.com> writes:
> > Tom Lane wrote:
> >> Okay, but then how will you refer unambiguously to the rowtype object?
> 
> > What about casting with the keyord ROW?
> > func(ROW table)
> > always refers to the row-type of table "table" even if there is
> > a column called "table".
> 
> Strikes me as gratuituously different from the way everything else is
> done.  We have .* and %ROWTYPE and so forth, and they're all suffixes.
> The closest analogy to your ROW syntax is CAST, but it doesn't alter the
> initial interpretation of its argument.
> 

I didn't mean literally that way, I just wanted to add a keyword for
solving ambiguity (when there is one).

You are right, it should be:

func(table%ROWTYPE)  




-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Wed, 23 Jan 2002 16:57:08 -0500
Fernando Nasser <fnasser@redhat.com>
Re: Schemas vs. PostQUEL: resolving qualified identifiers