Message-ID: <3C4EFD15.882B0785@redhat.com>
Date: Wed, 23 Jan 2002 13:12:37 -0500
From: Fernando Nasser <fnasser@redhat.com>
Organization: Red Hat , Inc. - Toronto
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
	pgsql-hackers@postgresql.org
Subject: Re: Schemas vs. PostQUEL: resolving qualified identifiers
References: <46C15C39FEB2C44BA555E356FBCD6FA42128D9@m0114.s-mxs.net>
	<2521.1011798379@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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