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 :-)
Joe
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
