Re: [BUGS] Stack not being popped correctly (was: Re: [HACKERS] plpgsql lacks generic identifier for record in triggers...)
Which, doesn't work as expected as it seems as though there's something left behind on the stack that shouldn't be. Here's the case to reproduce (doesn't involve pgmemcache): test=# CREATE FUNCTION t5_func() RETURNS TRIGGER AS 'BEGIN EXECUTE TRUE; RETURN NULL; END;' LANGUAGE 'plpgsql'; What are you expecting "execute true" to do? Behave the same as PERFORM? Ugh, how humiliating. When writing my pgmemcache presentation, I erroneously wrote EXECUTE instead of PERFORM. When sending off that little flurry of emails, I was updating my pgmemcache presentation and subconsciously propagated the error w/o even thinking about it. :-/ Thanks, I'll take that pumpkin pie on my face. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Stack not being popped correctly (was: Re: [HACKERS] plpgsql lacks generic identifier for record in triggers...)
Sean Chittenden <[EMAIL PROTECTED]> writes: > Which, doesn't work as expected as it seems as though there's something > left behind on the stack that shouldn't be. Here's the case to > reproduce (doesn't involve pgmemcache): > test=# CREATE FUNCTION t5_func() RETURNS TRIGGER AS 'BEGIN EXECUTE > TRUE; RETURN NULL; END;' LANGUAGE 'plpgsql'; What are you expecting "execute true" to do? The argument of EXECUTE is a string, not a boolean, and it's supposed to be a string that looks like a SQL command. The result > ERROR: syntax error at or near "t" at character 1 > QUERY: t > CONTEXT: PL/pgSQL function "t5_func" line 1 at execute statement > LINE 1: t > ^ is pretty much what I'd expect considering that plpgsql will do whatever it takes to coerce the expression result to text. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] Stack not being popped correctly (was: Re: [HACKERS] plpgsql lacks generic identifier for record in triggers...)
[snip] Err... wait, this is a classic case of send first then
finishing to pondering the gripe.
And sending a reply to ones self without actually testing my suggestion.
db=# CREATE FUNCTION schma.tbl_inval() RETURNS TRIGGER AS 'BEGIN
EXECUTE public.mc_init();
EXECUTE public.mc_delete(''mc_key'');
RETURN NULL;
END;' LANGUAGE 'plpgsql';
db=# CREATE TRIGGER tbl_inval_trg AFTER INSERT OR UPDATE OR DELETE ON
schma.tbl FOR EACH STATEMENT EXECUTE PROCEDURE schma.tbl_inval();
Which, doesn't work as expected as it seems as though there's something
left behind on the stack that shouldn't be. Here's the case to
reproduce (doesn't involve pgmemcache):
test=# CREATE TABLE t5 (i int);
Time: 35.294 ms
test=# CREATE FUNCTION t5_func() RETURNS TRIGGER AS 'BEGIN EXECUTE
TRUE; RETURN NULL; END;' LANGUAGE 'plpgsql';
Time: 101.701 ms
test=# CREATE TRIGGER t5_func_trg AFTER INSERT ON t5 FOR EACH STATEMENT
EXECUTE PROCEDURE t5_func();
Time: 62.345 ms
test=# INSERT INTO t5 VALUES (1);
ERROR: syntax error at or near "t" at character 1
QUERY: t
CONTEXT: PL/pgSQL function "t5_func" line 1 at execute statement
LINE 1: t
^
Doh! Can someone with plpgsql foo look into this? -sc
--
Sean Chittenden
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
