Kyle wrote:
> The only complication is
> that there are a class of records which the user should be able to view, but not
> modify. For example,
> the employee can create and modify working records as long as the only
> modification to their status
> is to move them on to "open status" (creating
Jan Wieck wrote:
> Tom Lane wrote:
>
> > This might be better done with a trigger than a rule. For one thing,
> > a trigger can easily raise an exception. MHO is that rules are good
> > when you need to update multiple rows in other tables when certain
> > things happen. If you just want to va
Tom Lane wrote:
Kyle <[EMAIL PROTECTED]> writes:
> If someone happens to know the primary key of a record they should
not be
> able to access, and they try to update it, I would like the backend
to
> ignore the query (or better yet, raise an exception but I haven't
figured
> out how to do that).
Tom Lane wrote:
> Kyle <[EMAIL PROTECTED]> writes:
> > If someone happens to know the primary key of a record they should not be
> > able to access, and they try to update it, I would like the backend to
> > ignore the query (or better yet, raise an exception but I haven't figured
> > out how to
Tom Lane wrote:
> Kyle <[EMAIL PROTECTED]> writes:
> > If someone happens to know the primary key of a record they should not be
> > able to access, and they try to update it, I would like the backend to
> > ignore the query (or better yet, raise an exception but I haven't figured
> > out how to d
Jan Wieck wrote:
Tom Lane wrote:
> Kyle <[EMAIL PROTECTED]> writes:
> > ERROR: Cannot update a view without an appropriate rule.
>
> 7.1 insists that you provide an *unconditional* DO INSTEAD rule
> for a view. What do you think was happening on your old database
> when the "where old.status =
Tom Lane wrote:
> Kyle <[EMAIL PROTECTED]> writes:
> > ERROR: Cannot update a view without an appropriate rule.
>
> 7.1 insists that you provide an *unconditional* DO INSTEAD rule
> for a view. What do you think was happening on your old database
> when the "where old.status = 'appr'" clause was
Kyle <[EMAIL PROTECTED]> writes:
> ERROR: Cannot update a view without an appropriate rule.
7.1 insists that you provide an *unconditional* DO INSTEAD rule
for a view. What do you think was happening on your old database
when the "where old.status = 'appr'" clause wasn't satisfied?
Nothing good
