(because our legacy application, which won't change, is using the underlying tables. We can't do step #5).<br /><br
/>Bryce Nesbitt wrote: <blockquote cite="mid:47B1580A.7050703@obviously.com" type="cite"><pre wrap="">Yes, the view
approachhas some advantages. But it still leaves the
underlying tables naked to modification.
And since the most likely error is... well... me (or another admin) at
the SQL prompt, we want underlying tables protected also.
chester c young wrote: </pre><blockquote type="cite"><pre wrap="">instead of triggers I use update-able views and
permissions.
1. all dml goes through the view
2. use rules on the view to do dml to the table
3. in rules prevent updating all/any columns when whatever
4. grant dml to view to your pgconnect user
5. revoke dml from table to your pgconnect user
imho another instance where rules rule. for example, you can easily
fit logging into the same view. </pre></blockquote><pre wrap=""> </pre></blockquote><br /><pre class="moz-signature"
cols="100">--
----
Visit <a class="moz-txt-link-freetext" href="http://www.obviously.com/">http://www.obviously.com/</a>
</pre>