From: | Steven Winfield <Steven(dot)Winfield(at)cantabcapital(dot)com> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | RE: A little RULE help? |
Date: | 2018-01-25 23:34:01 |
Message-ID: | E9FA92C2921F31408041863B74EE4C2001A47850EF@CCPMAILDAG03.cantab.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Maybe this?:
https://www.postgresql.org/docs/10/static/sql-createrule.html<https://www.postgresql.org/docs/10/static/sql-createrule.html>
"There is a catch if you try to use conditional rules for complex view
updates: there must be an unconditional INSTEAD rule for each action you
wish to allow on the view. If the rule is conditional, or is not
INSTEAD, then the system will still reject attempts to perform the
update action, because it thinks it might end up trying to perform the
action on the dummy table of the view in some cases. If you want to
handle all the useful cases in conditional rules, add an unconditional
DO INSTEAD NOTHING rule to ensure that the system understands it will
never be called on to update the dummy table. Then make the conditional
rules non-INSTEAD; in the cases where they are applied, they add to the
default INSTEAD NOTHING action. (This method does not currently work to
support RETURNING queries, however.)"
Thanks, I saw that - but none of my rules are conditional, and they are all INSTEAD OF, so I didn't think that was the problem.
FYI, I gave up on RULE's a while back. Triggers are a lot easier to
figure out and maintain.
These rules (including the non-working UPDATE rule) seemed fairly small and quite readable,
so I didn't think maintenance would be a problem.
Debugging this is a bit harder, however...
Steve.
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2018-01-25 23:41:26 | Re: A little RULE help? |
Previous Message | Adrian Klaver | 2018-01-25 23:25:33 | Re: A little RULE help? |