2009/3/9 Ryan Bradetich <rbradetich@gmail.com>:
> On Sun, Mar 8, 2009 at 4:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Ryan Bradetich <rbradetich@gmail.com> writes:
>>> This is one of the things I wanted to start looking at for 8.5.
>>> My idea was to optionally use : or @ (not sure which is more popular) to
>>> specify this token is only a variable.
>>
>> This whole line of thought is really a terrible idea IMHO. plpgsql is
>> supposed to follow Oracle's pl/sql syntax, not invent random syntax of
>> its own. I believe that 80% of the problems here are occurring because
>> we used a crude substitution method that got the priorities backwards
>> from the way Oracle does it.
>
> Fair Enough. I just hope what every solution the community decides upon
> solves this problem. It is a very annoying problem to track down and I tend
> to get even more agitated when I figure out this is the problem.
>
> I do not want to distract from the release efforts, so I will withhold further
> comments until the 8.5 development cycle.
>
We could relative simple don't add OUT variables into namespace.
Personally I prefer using dynamic sql for this case - 8.4 will support
RETURN QUERY EXECUTE too, but I don't see big problem in following
solution. With special interpret parameter #without_out_paramnames (or
some similar) we should protect "nice" out variables.
/* out parameters are accessible via $notation */
create function foo(OUT nicevar integer) returns setof record as $$
#without_out_paramnames
begin return query select nicevar from .....
end
$$ language ...
with dynamic sql it is easy too
create function foo(out nicevar integer) returns ...
begin return query execute 'select nicevar from ... '
end
$$ language
regard
Pavel Stehule
some special prefixes or special syntax is some what I dislike.
> Thanks,
>
> - Ryan
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
