[BUGS] BUG #1781: result of cascading triggers not available until function exits.

2005-07-23 Thread Andrew Smith

The following bug has been logged online:

Bug reference:  1781
Logged by:  Andrew Smith
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 7.4.6
Operating system:   Debian GNU/Linux 3.1
Description:result of cascading triggers not available until
function exits.
Details: 

CREATE TABLE master(value INTEGER);
CREATE TABLE detail(value INTEGER,parent INTEGER);

CREATE FUNCTION aftermaster() RETURNS TRIGGER AS '
BEGIN
INSERT INTO detail(value,parent)
VALUES(10,NEW.value);
INSERT INTO detail(value,parent)
VALUES(20,NEW.value);
RETURN NULL;
END;
' LANGUAGE plpgsql;

CREATE TRIGGER aftermaster AFTER INSERT OR UPDATE ON master
FOR EACH ROW EXECUTE PROCEDURE aftermaster();

CREATE OR REPLACE FUNCTION dostuff() RETURNS VOID AS '
DECLARE
counter INTEGER;
BEGIN
INSERT INTO master(value) VALUES(1);
SELECT COUNT(*) INTO counter FROM detail;
RAISE NOTICE ''counter = %'',counter;
RETURN NULL;
END
' LANGUAGE plpgsql;

/*
on PostgreSQL 8.0 log output is 'counter = 2'
but for version 7.4.6 log output is 'counter = 0'
*/

SELECT dostuff();
SELECT COUNT(*) FROM detail;

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


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

2005-07-23 Thread Dave Chapeskie
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, you don't need a function at all:
> 
> regression=# create or replace function copyit(text) returns text as $$
> regression$# declare tmp text;
> regression$# begin
> regression$#   tmp := $1;
> regression$#   tmp := tmp;
> regression$#   return tmp;
> regression$# end$$ language plpgsql stable;
> CREATE FUNCTION
> regression=# select copyit('foo');
> ERROR:  out of memory
> DETAIL:  Failed on request of size 1065320319.
> CONTEXT:  PL/pgSQL function "copyit" line 4 at assignment
> regression=#
> 
> 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().

Given that this occurs for almost any assignment of the form
"x := any expression with x" it's hard to avoid without rewritting a lot
of basic assignments with "tmp:=x; x:=foo(tmp)" which is ugly.

We can't use memory checking with this and even without memory checking
I don't trust that memory isn't getting spamed in some situations.
After all it's referencing free'd memory.

-- 
Dave Chapeskie

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [BUGS] BUG #1781: result of cascading triggers not available

2005-07-23 Thread Stephan Szabo

On Sat, 23 Jul 2005, Andrew Smith wrote:

> The following bug has been logged online:
>
> Bug reference:  1781
> Logged by:  Andrew Smith
> Email address:  [EMAIL PROTECTED]
> PostgreSQL version: 7.4.6
> Operating system:   Debian GNU/Linux 3.1
> Description:result of cascading triggers not available until
> function exits.

I don't think the 8.0 changes are a candidate for patching to earlier
versions, so I think the only option is to upgrade if you want the newer
behavior.

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


[BUGS] BUG #1782: unexpected EOF on client connection

2005-07-23 Thread Mohamed

The following bug has been logged online:

Bug reference:  1782
Logged by:  Mohamed
Email address:  [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system:   Suse Linux 9.3 Pro
Description:unexpected EOF on client connection
Details: 

While adding the user in postgresql we are geting thi error message = LOG
unexpected EOF on client connection

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq