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

Reply via email to