"Gevik Babakhani" <pgdev@xs4all.nl> 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
