odd behavior/possible bug
От | Joe Conway |
---|---|
Тема | odd behavior/possible bug |
Дата | |
Msg-id | 3F20241B.5080606@joeconway.com обсуждение исходный текст |
Ответы |
Re: odd behavior/possible bug
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: