On Mon, May 11, 2015 at 7:11 PM, Andres Freund <and...@anarazel.de> wrote: > Do I understand correctly that you cut this out because there > essentially was a ruleutils bug with with EXCLUDED? If so, I don't find > that acceptable. I'm pretty strictly convincded that independent of rule > support, we shouldn't add things to insert queries that get_query_def > can't deparse.
No, that wasn't the reason -- deparsing itself works fine. That code remains within ruleutils.c because I agree with this principle of yours. I tested the deparsing logic before making the case added fail as unsupported. If you remove the new ereport() call that relates to non-suppport of ON CONFLICT DO UPDATE as a rule action, then the CREATE RULE still succeeds, and you can deparse the query just fine (by quering pg_rules, typically). You just get an error within the optimizer following rewriting of a query involving the application of a rule that specifies an ON CONFLICT DO UPDATE alternative/DO INSTEAD action. I found it would say: "variable not found in subplan target lists". I can't say that I explored the question very thoroughly, but it seems bothersome to have more than one relation involved in a Query involved in rewriting. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
