On Thu, Jan 19, 2012 at 1:58 AM, Hitoshi Harada <umi.tan...@gmail.com> wrote: > On Wed, Jan 18, 2012 at 1:11 AM, Hitoshi Harada <umi.tan...@gmail.com> wrote: >> On Sat, Jan 14, 2012 at 8:10 AM, Matthew Draper <matt...@trebex.net> wrote: >>> >>> I just remembered to make time to advance this from WIP to proposed >>> patch this week... and then worked out I'm rudely dropping it into the >>> last commitfest at the last minute. :/ >> >> The patch applies clean against master but compiles with warnings. >> functions.c: In function ‘prepare_sql_fn_parse_info’: >> functions.c:212: warning: unused variable ‘argnum’ >> functions.c: In function ‘sql_fn_post_column_ref’: >> functions.c:341: warning: implicit declaration of function >> ‘ParseFuncOrColumn’ >> functions.c:345: warning: assignment makes pointer from integer without a >> cast >> >> (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. 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. > > 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. > > I mark this "Waiting on Author" for now.
It's been a few days since my last comment, but are you sending a new patch? If there's no reply, I'll make it Returned with Feedback. 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
