Re: Patch: Allow SQL-language functions to reference parameters by parameter name

On Thu, Feb 2, 2012 at 3:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> [ working on this patch now ... ]
>
> Matthew Draper <matthew(at)trebex(dot)net> writes:
>> On 25/01/12 18:37, Hitoshi Harada wrote:
>>> Should we throw an error in such ambiguity? Or did you make it happen
>>> intentionally? If latter, we should also mention the rule in the
>>> manual.
>
>> I did consider it, and felt it was the most consistent:
>
> I believe the issue here is that a two-part name A.B has two possible
> interpretations (once we have eliminated table references supplied by
> the current SQL command inside the function): per the comment,
>
>     * A.B        A = record-typed parameter name, B = field name
>     *            OR: A = function name, B = parameter name
>
> If both interpretations are feasible, what should we do?  The patch
> tries them in the above order, but I think the other order would be
> better.  My argument is this: the current behavior doesn't provide any
> "out" other than changing the function or parameter name.  Now
> presumably, if someone is silly enough to use a parameter name the same
> as the function's name, he's got a good reason to do so and would not
> like to be forced to change it.  If we prefer the function.parameter
> interpretation, then he still has a way to get to a field name: he just
> has to use a three-part name function.parameter.field.  If we prefer the
> parameter.field interpretation, but he needs to refer to a scalar
> parameter, the only way to do it is to use an unqualified reference,
> which might be infeasible (eg, if it also matches a column name exposed
> in the SQL command).
>
> Another problem with the current implementation is that if A matches a
> parameter name, but ParseFuncOrColumn fails (ie, the parameter is not of
> composite type or doesn't contain a field named B), then the hook just
> fails to resolve anything; it doesn't fall back to consider the
> function-name-first alternative.  So that's another usability black
> mark.  We could probably complicate the code enough so it did consider
> the function.parameter case at that point, but I don't think that there
> is a strong enough argument for this precedence order to justify such
> complication.
>
> In short, I propose swapping the order in which these cases are tried.

+1 from me.

Thanks,
--
Hitoshi Harada