On Mon, Jun 20, 2005 at 03:44:24PM -0400, Tom Lane wrote:
I [Tom Lane] wrote:
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.
For that matter,
Dave Chapeskie [EMAIL PROTECTED] 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 following bug has been logged online:
Bug reference: 1723
Logged by: Dave Chapeskie
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.6
Operating system: FreeBSD 5.x
Description:array_cat() bug when passed empty array
Details:
I believe this bug still
I wrote:
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.
For that matter, you don't need a function at all:
regression=# create or replace function
Dave Chapeskie [EMAIL PROTECTED] 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
