On 19/01/12 20:28, Hitoshi Harada wrote:
>> (Now it occurred to me that forgetting the #include parse_func.h might
>> hit this breakage..., so I'll fix it here and continue to test, but if
>> you'll fix it yourself, let me know)
>
> I fixed it here and it now works with my environment.
Well spotted; that's exactly what I'd done. :/
> The regression tests pass, the feature seems working as aimed, but it
> seems to me that it needs more test cases and documentation. For the
> tests, I believe at least we need "ambiguous" case given upthread, so
> that we can ensure to keep compatibility. For the document, it should
> describe the name resolution rule, as stated in the patch comment.
Attached are a new pair of patches, fixing the missing include (and the
other warning), plus addressing the above.
I'm still not sure whether to just revise (almost) all the SQL function
examples to use parameter names, and declare them the "right" choice; as
it's currently written, named parameters still seem rather second-class.
> Aside from them, I wondered at first what if the function is
> schema-qualified. Say,
>
> CREATE FUNCTION s.f(a int) RETURNS int AS $$
> SELECT b FROM t WHERE a = s.f.a
> $$ LANGUAGE sql;
>
> It actually errors out, since function-name-qualified parameter only
> accepts function name without schema name, but it looked weird to me
> at first. No better idea from me at the moment, though.
By my reading of (a draft of) the spec, Subclause 6.6, "<identifier
chain>", Syntax Rules 8.b.i-iii, the current behaviour is correct.
But I join you in wondering whether we should permit the function name
to be schema-qualified anyway.
Matthew
--
matthew@trebex.net