[HACKERS] Mismatched parentheses when creating a rule with multiple action queries
PostgreSQL 7.3.2. The parser does not seem to like semicolon between action queries: (Mismatched parentheses) So, it makes impossible to create a rule with more than one action query. Or am I missing something? CREATE RULE my_insert_rule AS ON INSERT TO my_view DO INSTEAD ( INSERT INTO my_table1... ; INSERT INTO my_table2... ); The rule with just one action works fine: DO INSTEAD ( INSERT INTO my_table1... ); ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Mismatched parentheses when creating a rule with multiple action queries
The problem happens only when running this query from the plpgsql function... So it must be a bug specific to plpgsql parser. -Original Message- From: Yurgis Baykshtis Sent: Wednesday, May 28, 2003 1:07 PM To: [EMAIL PROTECTED] Subject: Mismatched parentheses when creating a rule with multiple action queries PostgreSQL 7.3.2. The parser does not seem to like semicolon between action queries: (Mismatched parentheses) So, it makes impossible to create a rule with more than one action query. Or am I missing something? CREATE RULE my_insert_rule AS ON INSERT TO my_view DO INSTEAD ( INSERT INTO my_table1... ; INSERT INTO my_table2... ); The rule with just one action works fine: DO INSTEAD ( INSERT INTO my_table1... ); ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Mismatched parentheses when creating a rule with multiple action queries
Yurgis Baykshtis [EMAIL PROTECTED] writes: The problem happens only when running this query from the plpgsql function... So it must be a bug specific to plpgsql parser. It's actually plpgsql trying to be helpful and detect errors. 99% of the time I think this behavior would be considered a feature rather than a bug --- issuing CREATE RULE from a plpgsql function is well out past the second standard deviation (even with only one action in it ;-)), and AFAIK there are no other cases where a semicolon could be embedded in a SQL construct. So I'm inclined to leave it as-is. regards, tom lane ---(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