| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Minor ON CONFLICT related fixes |
| Date: | 2015-05-12 02:22:47 |
| Message-ID: | CAM3SWZSsWwQ9gGF_-3UCwexHRrUMS++Tz7=XrhPLoqcBUoRFgA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, May 11, 2015 at 7:11 PM, Andres Freund <andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2015-05-12 02:33:02 | Re: Minor ON CONFLICT related fixes |
| Previous Message | Andres Freund | 2015-05-12 02:11:24 | Re: Minor ON CONFLICT related fixes |