odd behavior/possible bug

From: Joe Conway <mail(at)joeconway(dot)com>
To: "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Subject: odd behavior/possible bug
Date: 2003-07-24 18:23:23
Message-ID: 3F20241B.5080606@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

I created a function thus:

CREATE OR REPLACE FUNCTION dwarray(anyelement, anyelement)
RETURNS anyarray AS '
SELECT ARRAY[$1,$2]
' LANGUAGE 'sql' IMMUTABLE STRICT;

My hope was to use STRICT to get the following behavior: if either or
both arguments are NULL, I get a NULL. If both are non-NULL, I get an
array. Seems simple enough at first glance. Here's what I get when I try
it out:

regression=# select dwarray(1,2);
dwarray
---------
{1,2}
(1 row)
regression=# select dwarray(1,null) is null;
?column?
----------
t
(1 row)

regression=# select dwarray(null,2) is null;
?column?
----------
t
(1 row)

So far so good. But look at this one:
regression=# select dwarray(null,null);
ERROR: cannot determine ANYARRAY/ANYELEMENT type because input is UNKNOWN

This happens because enforce_generic_type_consistency() can't resolve
the return type from the NULLs which are typed as UNKNOWN. This call is
made from ParseFuncOrColumn().

Should ParseFuncOrColumn() bypass the call to
enforce_generic_type_consistency() when all arguments are NULL?

The next item is a bit more strange. Create a table and load some data:
create table t(f1 int, f2 float, f3 float);
insert into t values(1,11.1,21.1);
insert into t values(1,11.2,21.2);
insert into t values(1,11.3,21.3);
insert into t values(1,11.4,null);
insert into t values(1,null,21.5);
insert into t values(1,null,null);

Now call the same function:
regression=# select dwarray(f2,f3) from t;
ERROR: arrays cannot have NULL elements

This call makes it all the way to ExecEvalArray(), which means that
dwarray() is getting evaluated even though it is declared STRICT and has
been called with NULL inputs. That shouldn't happen, should it?

Joe

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-07-24 18:36:54 Re: v7.3.4 bundled ...
Previous Message Adam Haberlach 2003-07-24 18:07:12 Re: Really odd corruption problem: cannot open pg_aggregate: No such file or directory

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2003-07-24 19:04:59 Re: odd behavior/possible bug
Previous Message Serguei Mokhov 2003-07-24 13:21:04 Russian NLS Update: libpq-ru.po