Joe Conway <[EMAIL PROTECTED]> writes:
> Inside the the function body, you can access the actual function call
> time *argument* types to create local variables by using the %type
> construct, e.g.:
> v_myvar $1%type;
> However, there is currently is *no way* to create a variable based on
> the return type, severely limiting the utility of polymorphic plpgsql
> functions.
Good point. I agree this is worth addressing.
> So what does the attached patch do? It adds an additional variable to
> any function with a polymorphic return type (only), called $0, which
> represents the actual function call time return type.
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.
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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
