From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Dave Chapeskie" <pgsql(at)ddm(dot)wox(dot)org> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #1723: array_cat() bug when passed empty array |
Date: | 2005-06-20 19:40:21 |
Message-ID: | 20186.1119296421@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Dave Chapeskie" <pgsql(at)ddm(dot)wox(dot)org> writes:
> array_cat() has a bug when passed an empty array. The
> code attempts to optimise/short-circuit this case and
> returns a pointer to the non-empty argument. This is
> bad/wrong. Especially when used in a construct like:
> foo := foo || <some_array>
> since after array_cat() returns exec_assign_value()
> will pfree() 'foo' and then attempt to assign the now
> invalid result that points to 'foo'.
Actually, I would say the bug is exec_assign_value's. There is nothing
at all wrong with a function returning one of its input values; for
example the smaller/larger functions all do that. Let's see...
regression=# create or replace function smal(text,text) returns text as $$
regression$# declare tmp text;
regression$# begin
regression$# tmp := $1;
regression$# tmp := text_smaller(tmp, $2);
regression$# return tmp;
regression$# end$$ language plpgsql stable;
CREATE FUNCTION
regression=# select smal('abc', '123');
smal
------
123
(1 row)
regression=# select smal('123', 'abc');
ERROR: out of memory
DETAIL: Failed on request of size 1065320319.
CONTEXT: PL/pgSQL function "smal" line 4 at assignment
regression=#
It's very surprising no one noticed this before. Thanks for the report!
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-06-20 19:44:24 | Re: BUG #1723: array_cat() bug when passed empty array |
Previous Message | John Hansen | 2005-06-20 19:31:41 | Re: BUG #1721: mutiple bytes character string comaprison error |