Tom Lane wrote:
Yeah, rewrite rules are going to be a *serious* stumbling block to
this whole concept. Maybe we should just punt the project until we
have a clear idea of how to do that.
I've implemented rewrite rules for writeable CTEs, and at least now I
don't see any problems except one. I can't seem to think of what would
be the correct behaviour in this case:
=> CREATE rule foo_rule AS ON INSERT TO foo DO ALSO SELECT * FROM bar;
CREATE RULE
=> WITH t AS (INSERT INTO foo VALUES(0) RETURNING *) SELECT * FROM t;
If you rewrite the query as it is rewritten in the top-level case, you
get a plan such as this:
-------------------------------------------------------
CTE Scan ON t (cost=0.01..0.03 rows=1 width=4)
CTE t
-> INSERT (cost=0.00..0.01 rows=1 width=0)
-> Result (cost=0.00..0.01 rows=1 width=0)
Seq Scan ON bar (cost=0.00..34.00 rows=2400 width=4)
and now you have *two* SELECT statements. Currently the portal code
gives the output of the "Seq Scan ON bar" here which is IMO very
surprising. Does ignoring the rule here sound sane or should we error
out? Or does someone have a better idea? DO ALSO INSERT/UPDATE/DELETE
works as expected here.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
