On Thu, Feb 2, 2012 at 3:19 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > [ working on this patch now ... ] > > Matthew Draper <matt...@trebex.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
