Tom Lane wrote:
Ugh.  That seems like a really crude way to handle things.  In the first
place, a variable adds overhead whether you need it or not; in the
second place, what's the value of the variable if I try to fetch it,
or the effects if I assign to it?  $0 seems like a rather
randomly-chosen notation.

Well, not exactly random. In plpgsql the arguments are created inside the function body as $1, $2, etc., so $0 seemed reasonable for the return type variable. It was also very non-intrusive, since the lexer already was set up to recognize \${digit}+, and $0 was going unused.

Overhead is only added to functions returning polymorphic. All others incur no overhead, except bypassing an if(){code-block}.

If you try to fetch the variable, it will be NULL. I don't think you can assign to it any more than you can $1,$2, etc for the arguments (but I'll check that out).

I'm wondering whether we couldn't invent some notation along the lines
of "%rettype" to handle this issue.  (But the other %foo notations in
plpgsql modify some argument, and I'm not sure what %rettype should
modify.)  Or perhaps "functionname%type", although that seems subtly
wrong for reasons I can't quite put my finger on at this late hour.
Anyway, I'd like a representation that doesn't involve a phony variable.

Any other implementation will be much more intrusive, involving the lexer and probably three new functions, ala plpgsql_parse_wordtype(), plpgsql_parse_dblwordtype(), and plpgsql_parse_tripwordtype() (or at least significant hacking on the three mentioned).

But if that's the way you prefer, I'll get on it :-)


---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster

Reply via email to