Re: Schemas vs. PostQUEL: resolving qualified identifiers
От | Fernando Nasser |
---|---|
Тема | Re: Schemas vs. PostQUEL: resolving qualified identifiers |
Дата | |
Msg-id | 3C4EFD15.882B0785@redhat.com обсуждение исходный текст |
Ответ на | Re: Schemas vs. PostQUEL: resolving qualified identifiers ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>) |
Ответы |
Re: Schemas vs. PostQUEL: resolving qualified identifiers
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: