From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Missing array support |
Date: | 2003-06-30 01:01:53 |
Message-ID: | 3EFF8C01.1060709@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>
>>Included in the patch, I changed SQL language functions so that they
>>could be declared with and use polymorphic types.
>
> I'm not convinced that will work ... in particular, does the parsetree
> get fixed correctly when a SQL function is inlined?
As far as I can see (and verified through testing), evaluate_function()
is no problem; it passes on the args from the original FuncExpr at about
line 1690 of clauses.c
newexpr->args = args;
and they get found just fine in init_sql_fcache.
regression=# CREATE OR REPLACE FUNCTION ffp(anyarray) returns anyarray
as 'select $1' language 'sql' strict immutable;
CREATE FUNCTION
regression=# select ffp(array[1]);
NOTICE: init_sql_fcache: arg 0, oid 1007
NOTICE: simplify_function: !newexpr = 0, allow_inline = 1
ffp
-----
{1}
(1 row)
When the function is defined as above, getting it to try to inline:
regression=# select ffp(array[f]) from (select 1 as f) as ss;
NOTICE: simplify_function: !newexpr = 1, allow_inline = 1
NOTICE: inline_function: I'm here
NOTICE: init_sql_fcache: arg 0, oid 1007
ffp
-----
{1}
(1 row)
It doesn't get inlined (as defined above) because it fails this check in
inline_function():
/* Forget it if declared return type is tuple or void */
result_typtype = get_typtype(funcform->prorettype);
if (result_typtype != 'b' &&
result_typtype != 'd')
return NULL;
So the only way a problem can arise given the patch I sent, is when the
function accepts polymorphic arguments, but does not return polymorphic:
regression=# drop FUNCTION ffp(anyarray);
DROP FUNCTION
regression=# CREATE OR REPLACE FUNCTION ffp(anyarray) returns int[] as
'select array[1]' language 'sql';
CREATE FUNCTION
regression=# select ffp(array[f]) from (select 1 as f) as ss;
NOTICE: simplify_function: !newexpr = 1, allow_inline = 1
NOTICE: inline_function: I'm here
NOTICE: inline_function: simplified
ffp
-----
{1}
(1 row)
So I'd propose that we put another check in inline_function(), and
reject attempts to inline functions with polymorphic arguments. The
other bases are already covered and we already have the proc tuple
available in inline_function(). Sound OK?
Thanks,
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | PeterKorman | 2003-06-30 01:38:35 | Re: persistant psql feature suggestion |
Previous Message | Jim C. Nasby | 2003-06-29 23:11:53 | pgsql-hackers@postgresql.org |
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2003-06-30 02:56:16 | Re: [HACKERS] Missing array support |
Previous Message | Joe Conway | 2003-06-29 22:32:11 | Re: [HACKERS] Missing array support |