From: Tom Lane <tgl@sss.pgh.pa.us>
> In view of this, maybe the right thing is to disallow modifying CTEs
> in rule actions in the first place. I see we already do that for
> views (i.e. ON SELECT rules), but they're not really any safer in
> other types of rules.
You meant by views something like the following, didn't you?
postgres=# create view myview as with t as (delete from b) select * from a;
ERROR: views must not contain data-modifying statements in WITH
OTOH, the examples Greg-san showed do not contain CTE in the rule action, but in the query that the rule is applied to.
So, I think the solution would be something different.
> Given that non-SELECT rules are an undertested
> legacy thing, I'm not that excited about moving mountains to make
> this case possible.
> That semantic issue doesn't get any less pressing just because the query
> was generated by rewrite. So I now think that what we have to do is
> throw an error if we have a modifying CTE and sub_action is different
> from rule_action. Not quite sure how to phrase the error though.
So, how about just throwing an error when the original query (not the rule action) has a data-modifying CTE? The error
messagewould be something like "a query containing a data-modifying CTE cannot be executed because there is some rule
applicableto the relation". This may be overkill and too many regression tests might fail, so we may have to add some
conditionto determine if we error out.
Or, I thought Greg-san's patch would suffice. What problem do you see in it?
I couldn't imagine what "mountains" are. Could you tell me what's that?
Regards
Takayuki Tsunakawa