Skip site navigation (1) Skip section navigation (2)

Re: BUG #1723: array_cat() bug when passed empty array

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dave Chapeskie <dchapeskie(at)sandvine(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1723: array_cat() bug when passed empty array
Date: 2005-07-22 15:45:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Dave Chapeskie <dchapeskie(at)sandvine(dot)com> writes:
> On Mon, Jun 20, 2005 at 03:44:24PM -0400, Tom Lane wrote:
>> This makes it perfectly clear that the problem is that exec_assign_value
>> must copy the given value before it frees the old, just in case they're
>> the same.  (Hmm, I wonder if we can shortcircuit the whole thing ...)

> Anyone working on fixing this?  I'd have tried but I didn't want to dive
> into exec_assign_value() and exec_cast_value().

Done some time ago, I think [ digs in CVS log... ]  yeah, here it is:

2005-06-20 16:44  tgl

	* src/pl/plpgsql/src/: pl_exec.c (REL7_3_STABLE), pl_exec.c
	(REL7_4_STABLE), pl_exec.c (REL7_2_STABLE), pl_exec.c
	(REL8_0_STABLE), pl_exec.c: plpgsql's exec_assign_value() freed the
	old value of a variable before copying/converting the new value,
	which meant that it failed badly on "var := var" if var is of
	pass-by-reference type.  Fix this and a similar hazard in
	exec_move_row(); not sure that the latter can manifest before 8.0,
	but patch it all the way back anyway.  Per report from Dave

You can get the patches from our CVS server.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2005-07-22 16:44:31
Subject: Re: abstime bug
Previous:From: Dave ChapeskieDate: 2005-07-22 15:41:04
Subject: Re: BUG #1723: array_cat() bug when passed empty array

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group