2007/5/3, Tom Lane <tgl@sss.pgh.pa.us>:
> Neil Conway <neilc@samurai.com> writes:
> > Pavel, my apologies for not getting back to you sooner.
> > On Wed, 2007-25-04 at 07:12 +0200, Pavel Stehule wrote:
> >> example: I have table with attr. cust_id, and I want to use parametrized
> >> view (table function) where I want to have attr cust_id on output.
>
> > Hmm, I see your point. I'm personally satisfied with adding a new
> > proargmode to solve this as you suggest.
>
> This will break client-side code that looks at proargmode, and I don't
> think the argument in favor is strong enough to justify that ...
>
can be. But similar changes was more times: named arguments, out,
inout attrb .. This depend on application. If any application is
written too simply then it can have problem. But which application
check proargmodes: pgadmin, phppgadmin, emsmanager, ... it's not
frequentation activity. And it's question for maintainers of this
applications. What difficult is change it? This syntax is usefull. It
lowers risk of name's colisition, and is more readable (if it do what
it have to do).
I am sorry, but I don't see sense of "new" table function syntax
without changes of proargmodes. Only shortcut for SETOF RECORD isn't
usefull. This syntax is standardised, is used in SQL/PSM which
PostgreSQL have to adapt this year, or next year, or maybe later, but
have to be adapted. And SQL/PSM knows only declared variables or
function's parameters. I forgot, it's can be usefull for SQL language
procedures. They don't use named arguments (how long?).
Regards
Pavel Stehule