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 == C
Simon Riggs 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 awfully dubious fro
On Sun, 2009-12-06 at 10:26 -0500, Tom Lane wrote:
> Simon Riggs 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 an
Simon Riggs 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 a small, but usef
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 curre
