Re: Opinion / advice needed for TODO: function params ref by name

Hello,

This is about:
http://archives.postgresql.org/pgsql-patches/2007-11/msg00028.php

In order to resolve <function name>.<parameter name> the check in
transformColumnRef goes into case 2 which is A.B

The ideal way to resolve the func.param in this case is to perform the
callback (hook)
after ALL the checks (like qualifiedNameToVar) are performed.

Unfortunately for func.param is this problematic because
qualifiedNameToVar and transformWholeRowRef/ParseFuncOrColumn
internally call RTE functions which justifiably throw an "ambiguous column
error".

I would like your opinion about the following implementations:

Only when parsing functions and only in case of A.B:

a) Check for func.param before qualifiedNameToVar and
transformWholeRowRef/ParseFuncOrColumn

result: func.param resolves correctly,
but: in case of a function name/parameter name being the same as
a table name / column name, the func.param will be resolved first.
for example:

create table func( id int, fld1 varchar );

create function func( id int, fld1 varchar ) ... as
$$
select func.id from func where func.id = func.id;
$$
language sql;

above will produce the unexpected result hence <function
name>.<parameter name>
will be resolved first.

b) step 1. call qualifiedNameToVar with implicitRTEOK = FALSE;
step 2. if no results then perform callback;
step 3. Next if no results then qualifiedNameToVar with
implicitRTEOK = TRUE (default);
step 4. if no result then continue as ParseFuncOrColumn

result: func.param resolves correctly
but: the order will be qualifiedNameToVar , CallBack , ParseFuncOrColumn.

I have tested both options (a) and (b)
Current regression test + new tests pass on Win and RH.

Any thoughts?

Regards,
Gevik.

------------------------------------------------
Gevik Babakhani

PostgreSQL NL http://www.postgresql.nl
TrueSoftware BV http://www.truesoftware.nl
------------------------------------------------

"Gevik Babakhani" <pgdev(at)xs4all(dot)nl> writes:
> Unfortunately for func.param is this problematic because
> qualifiedNameToVar and transformWholeRowRef/ParseFuncOrColumn
> internally call RTE functions which justifiably throw an "ambiguous column
> error".

What's the problem? If it's ambiguous within the query, it's ambiguous.

> a) Check for func.param before qualifiedNameToVar and
> transformWholeRowRef/ParseFuncOrColumn

This is 100% backwards.

regards, tom lane