[HACKERS] Allowing DML RULEs that produce Read Only actions during RO xacts

2009-12-06 Thread Simon Riggs
I would like to allow RULEs ON INSERT, ON UPDATE and ON DELETE during read only transactions iff they generate only SELECT statements that act INSTEAD OF the actual event. CREATE RULE foorah AS ON INSERT TO foo DO INSTEAD SELECT remote_insert(NEW.col1, NEW.col2, ...); The above rule is

Re: [HACKERS] Allowing DML RULEs that produce Read Only actions during RO xacts

2009-12-06 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes: I would like to allow RULEs ON INSERT, ON UPDATE and ON DELETE during read only transactions iff they generate only SELECT statements that act INSTEAD OF the actual event. I don't actually believe there is any use case for such a thing. This would be

Re: [HACKERS] Allowing DML RULEs that produce Read Only actions during RO xacts

2009-12-06 Thread Simon Riggs
On Sun, 2009-12-06 at 10:26 -0500, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: I would like to allow RULEs ON INSERT, ON UPDATE and ON DELETE during read only transactions iff they generate only SELECT statements that act INSTEAD OF the actual event. I don't actually

Re: [HACKERS] Allowing DML RULEs that produce Read Only actions during RO xacts

2009-12-06 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes: On Sun, 2009-12-06 at 10:26 -0500, Tom Lane wrote: How would you reroute them without a non-read-only operation happening somewhere along the line? I showed how in my example. The non-read-only operation happens on a remote server. That seems

Re: [HACKERS] Allowing DML RULEs that produce Read Only actions during RO xacts

2009-12-06 Thread Simon Riggs
On Sun, 2009-12-06 at 10:26 -0500, Tom Lane wrote: + /* + * If we're running a SELECT, allow it. This ensures that a + * write rule such as ON INSERT DO SELECT can be executed in + * a read-only session. + */ + if (plannedstmt-commandType == CMD_SELECT)