"Gevik Babakhani" <[EMAIL PROTECTED]> writes:
> I have considered a noError boolean too.
> but please considered the following:
> step 1: call qualifiedNameToVar(noError = true), which generates an error
> but gets suppressed by noError parameter.
> step 2: process function parameter name for
> funct1.param1, check "funct1" == <the name of the current function>,
> which "funct1" is unknown/ambiguous (the name of the current function was
> "func" for example).
> In the case above I thought I somehow re-throw the error that
> was originally generated at step 1.
Yeah, you'd throw the same error number and message as that routine
would have thrown, but matching that is not rocket science ;-).
I don't see any value in trying to have only one instance of the
ereport() call instead of two --- it's going to cost you *more*
lines of code and *more* intellectual complexity to try to trap
and re-throw the error than it will cost to just have two identical
ereport() calls.
Although quite frankly I don't see any need to be touching
qualifiedNameToVar at all. It's already defined to return NULL if it
doesn't find the name anyplace in the query, which seems to me to be
what you want anyway. The only non-internal error it might raise is
"ambiguous name" which is fine. That's an error condition, and the
possibility that there is a function variable visible at an outer name
scoping level doesn't make it not an error.
The place where you need to be refactoring is probably in or around
the transformWholeRowRef/ParseFuncOrColumn sequence.
One thing that we need to think about is what is the priority of
function-variable matching compared to implicit RTE creation. I'm
inclined to think we should allow function variables to go first...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
