Kyle writes:
> Shouldn't the select access to the view trickle down to subordinate select functions?
I would think not.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 4: Don't 'kill -9'
Peter Eisentraut wrote:
Kyle writes:
> Peter Eisentraut wrote:
>
> > Kyle writes:
> >
> > > Is there a way to get this to work without granting update to
table b?
> >
> > Update to 7.1.]
>
> I'm on 7.1. Should an RI trigger under 7.1 run as the DBA or
as the current
> user?
Okay, we missed a few
Kyle writes:
> Peter Eisentraut wrote:
>
> > Kyle writes:
> >
> > > Is there a way to get this to work without granting update to table b?
> >
> > Update to 7.1.]
>
> I'm on 7.1. Should an RI trigger under 7.1 run as the DBA or as the current
> user?
Okay, we missed a few cases. Try the attach
On Wed, 25 Apr 2001, Kyle wrote:
> Peter Eisentraut wrote:
>
> > Kyle writes:
> >
> > > Is there a way to get this to work without granting update to table b?
> >
> > Update to 7.1.]
>
> I'm on 7.1. Should an RI trigger under 7.1 run as the DBA or as the current
> user?
IIRC, only the checks
Peter Eisentraut wrote:
> Kyle writes:
>
> > Is there a way to get this to work without granting update to table b?
>
> Update to 7.1.]
I'm on 7.1. Should an RI trigger under 7.1 run as the DBA or as the current
user?
>
>
> > Tom, I understand someone was working on setuid functions. Is that
Kyle writes:
> Is there a way to get this to work without granting update to table b?
Update to 7.1.
> Tom, I understand someone was working on setuid functions. Is that a
> long way off? It would be nifty if triggers could execute with the
> privileges of the user that created them rather th
Here's an interesting security problem: Suppose I create two tables:
create table a (
pk int4 primary key,
aval text
);
create table b (
fk int4 references a (pk)
on update cascade,
bval
);
Then I grant a user update to table a but not to table b. He should
be able to mod
