Re: odd behavior/possible bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: odd behavior/possible bug
Date: 2003-07-24 19:04:59
Message-ID: 17647.1059073499@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Joe Conway <mail(at)joeconway(dot)com> writes:
> So far so good. But look at this one:
> regression=# select dwarray(null,null);
> ERROR: cannot determine ANYARRAY/ANYELEMENT type because input is UNKNOWN

That seems correct to me. What would you expect to happen? There's no
type we could assign as the function's actual return type.

> 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?

I think what is happening is that the SQL function is getting inlined,
probably because the inlining logic thinks ARRAY[] is strict and so
there'd be no change in semantics.

We could probably hack the inlining logic to prevent it from inlining
the function in this scenario, but I wonder whether this doesn't say
that ExecEvalArray is behaving inconsistently. In other operations, any
NULL in means NULL out. Shouldn't it simply quietly return a NULL array
if one of the supplied elements is NULL?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nailah Ogeer 2003-07-24 19:21:41 Re: Postgres hash tables
Previous Message David Blasby 2003-07-24 18:55:19 Getting the current transaction's xid

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2003-07-24 20:47:59 Re: odd behavior/possible bug
Previous Message Joe Conway 2003-07-24 18:23:23 odd behavior/possible bug