"Gevik Babakhani" <[EMAIL PROTECTED]> writes: >> what about name's collision? Maybe is better use some prefix, >> like $ or :. Without it we only propagate one problem from >> plpgsql to others languages.
> Please explain. > Perhaps I am wrong, but plpgsql handles arsgument names before it > passes the query to be executed. Which is actually the Wrong Thing to do: really the parameters should be seen as being in a name scope that's outside that of the query (and thus ambiguous names should be resolved first as column names of the query). The proposed patch does this in the right order and so I think that Pavel's concern is without foundation. One point here is that it would be good to be able to qualify the argument names with the function name, for example create function myfunc(x int) ... select ... from t where t.x = myfunc.x If t has a column named x then this will be the only way that the function parameter x can be referenced within that query. We are partway to that point with plpgsql but haven't bitten the bullet of changing the lookup order. Note that this consideration is another reason for having a callback function that's responsible for trying to resolve unresolved names. I certainly wouldn't like to have a notion of "function name" wired into the parser API, and if we did do that it still wouldn't be sufficient for plpgsql which can have multiple block-label namespaces accessible at once. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly