Search Postgresql Archives

Re: CALL and named parameters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dominique Devienne <ddevienne@xxxxxxxxx> writes:
> I was expecting an error telling me the procedure exists, but the
> argument name used in the call didn't. Then it's obvious to me what
> mistake I made. If argument names don't participate in the function's
> signature, why should they participate in the lookup? Do the lookup
> based on name and arg types (and count), that gives you a possible
> overload set, which in my second attempt (with a ::name cast) WAS AN
> EXACT MATCH for the signature, then give me an error about the
> argument name, that does NOT tell me the function doesn't exist.
> That's what I would expect.

Criticism in the form of a patch is welcome ;-).  The problem here
is that the matching rules are far more complicated than you seem
to think.  It's not clear to me that we can definitively say that
"we would have had a match except the argument name was wrong".
If it is possible to know that, it's quite a few subroutines below
where the error is actually issued (see ParseFuncOrColumn ->
func_get_detail -> FuncnameGetCandidates -> MatchNamedCall).
Maybe there's some fairly painless change that could be made in
that rat's nest, but I lack enough caffeine to see it.

			regards, tom lane





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux