pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedA question on triggers
6+ messages / 4 participants
[nested] [flat]
* A question on triggers
@ 2000-02-16 13:58 Constantin Teodorescu <teo@flex.ro>
0 siblings, 1 reply; 6+ messages in thread
From: Constantin Teodorescu @ 2000-02-16 13:58 UTC (permalink / raw)
To: pgsql-interfaces
I have two tables "inputs" and "outputs" and they hold items and
quantities that are coming and going from a warehouse.
I have defined also another table "stock" that will hold the inventory
of that warehouse.
I have defined triggers on INSERT, UPDATE and DELETE on "inputs" and
"outputs" tables that update acordingly the "stock" table!
What's my problem?
Is there any chance to restrict the direct updates of any user to the
"stock" table?
So that the information in the "stock" table should be updated ONLY by
those triggers?
Thanks in advance,
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [INTERFACES] A question on triggers
@ 2000-02-16 16:23 Ed Loehr <eloehr@austin.rr.com>
parent: Constantin Teodorescu <teo@flex.ro>
0 siblings, 1 reply; 6+ messages in thread
From: Ed Loehr @ 2000-02-16 16:23 UTC (permalink / raw)
To: Constantin Teodorescu <teo@flex.ro>; +Cc: pgsql-interfaces
Constantin Teodorescu wrote:
>
> I have two tables "inputs" and "outputs" and they hold items and
> quantities that are coming and going from a warehouse.
>
> I have defined also another table "stock" that will hold the inventory
> of that warehouse.
>
> I have defined triggers on INSERT, UPDATE and DELETE on "inputs" and
> "outputs" tables that update acordingly the "stock" table!
>
> What's my problem?
>
> Is there any chance to restrict the direct updates of any user to the
> "stock" table?
> So that the information in the "stock" table should be updated ONLY by
> those triggers?
Just for kicks, here's a hack. Add a column named 'passwd' to the
stock table (with a bogus default value), then create an UPDATE
trigger on stock requiring the UPDATE to include a valid 'passwd'
column value that's only known (hard-coded) to your 'inputs' and
'outputs' triggers. Would that work?
Cheers,
Ed Loehr
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [INTERFACES] A question on triggers
@ 2000-02-16 18:23 Constantin Teodorescu <teo@flex.ro>
parent: Ed Loehr <eloehr@austin.rr.com>
0 siblings, 1 reply; 6+ messages in thread
From: Constantin Teodorescu @ 2000-02-16 18:23 UTC (permalink / raw)
To: Ed Loehr <eloehr@austin.rr.com>; +Cc: pgsql-interfaces
Ed Loehr wrote:
>
> Constantin Teodorescu wrote:
> >
> > I have two tables "inputs" and "outputs" and they hold items and
> > quantities that are coming and going from a warehouse.
> >
> > I have defined also another table "stock" that will hold the inventory
> > of that warehouse.
> >
> > I have defined triggers on INSERT, UPDATE and DELETE on "inputs" and
> > "outputs" tables that update acordingly the "stock" table!
> >
> > What's my problem?
> >
> > Is there any chance to restrict the direct updates of any user to the
> > "stock" table?
> > So that the information in the "stock" table should be updated ONLY by
> > those triggers?
>
> Just for kicks, here's a hack. Add a column named 'passwd' to the
> stock table (with a bogus default value), then create an UPDATE
> trigger on stock requiring the UPDATE to include a valid 'passwd'
> column value that's only known (hard-coded) to your 'inputs' and
> 'outputs' triggers. Would that work?
I think it will work! It's really a good idea!
But wouldn't be nice if PostgreSQL could offer a more elegant solution?
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [INTERFACES] A question on triggers
@ 2000-02-16 22:13 Tom Lane <tgl@sss.pgh.pa.us>
parent: Constantin Teodorescu <teo@flex.ro>
0 siblings, 1 reply; 6+ messages in thread
From: Tom Lane @ 2000-02-16 22:13 UTC (permalink / raw)
To: Constantin Teodorescu <teo@flex.ro>; +Cc: Ed Loehr <eloehr@austin.rr.com>; pgsql-interfaces
>>>> Is there any chance to restrict the direct updates of any user to the
>>>> "stock" table?
>>>> So that the information in the "stock" table should be updated ONLY by
>>>> those triggers?
> But wouldn't be nice if PostgreSQL could offer a more elegant solution?
Can't you do it with the normal GRANT/REVOKE access-control mechanism?
I'm pretty sure that for rules (views), the access rights for queries
issued within the rule are checked based on the owner of the rule, not
the user who invoked the rule. Triggers ought to work the same way,
though I haven't tried it. So you could make the trigger function and
the protected table owned by the same user, and then not grant write
permission on that table to anyone else.
regards, tom lane
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [INTERFACES] A question on triggers
@ 2000-02-17 18:04 Constantin Teodorescu <teo@flex.ro>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 6+ messages in thread
From: Constantin Teodorescu @ 2000-02-17 18:04 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Ed Loehr <eloehr@austin.rr.com>; pgsql-interfaces
Tom Lane wrote:
>
> >>>> Is there any chance to restrict the direct updates of any user to the
> >>>> "stock" table?
> >>>> So that the information in the "stock" table should be updated ONLY by
> >>>> those triggers?
>
> > But wouldn't be nice if PostgreSQL could offer a more elegant solution?
>
> Can't you do it with the normal GRANT/REVOKE access-control mechanism?
No. It didn't worked, that was my first idea!
> I'm pretty sure that for rules (views), the access rights for queries
> issued within the rule are checked based on the owner of the rule, not
> the user who invoked the rule. Triggers ought to work the same way,
> though I haven't tried it. So you could make the trigger function and
> the protected table owned by the same user, and then not grant write
> permission on that table to anyone else.
It seems it didn't work!
Constantin Teodorescu
^ permalink raw reply [nested|flat] 6+ messages in thread
* RE: [INTERFACES] A question on triggers
@ 2000-02-19 15:15 Hiroshi Inoue <Inoue@tpf.co.jp>
parent: Constantin Teodorescu <teo@flex.ro>
0 siblings, 0 replies; 6+ messages in thread
From: Hiroshi Inoue @ 2000-02-19 15:15 UTC (permalink / raw)
To: Constantin Teodorescu <teo@flex.ro>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Ed Loehr <eloehr@austin.rr.com>; pgsql-interfaces
> -----Original Message-----
> From: owner-pgsql-interfaces@postgreSQL.org
> [mailto:owner-pgsql-interfaces@postgreSQL.org]On Behalf Of
> Constantin Teodorescu
>
> Tom Lane wrote:
> >
> > > But wouldn't be nice if PostgreSQL could offer a more elegant
> solution?
> >
> > Can't you do it with the normal GRANT/REVOKE access-control mechanism?
>
> No. It didn't worked, that was my first idea!
>
> > I'm pretty sure that for rules (views), the access rights for queries
> > issued within the rule are checked based on the owner of the rule, not
> > the user who invoked the rule. Triggers ought to work the same way,
> > though I haven't tried it. So you could make the trigger function and
> > the protected table owned by the same user, and then not grant write
> > permission on that table to anyone else.
>
> It seems it didn't work!
>
Hmm,it seems to work for views(rules) but it doesn't work for functions.
It should work for stored procedures,shouldn't it ?
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2000-02-19 15:15 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2000-02-16 13:58 A question on triggers Constantin Teodorescu <teo@flex.ro>
2000-02-16 16:23 ` Ed Loehr <eloehr@austin.rr.com>
2000-02-16 18:23 ` Constantin Teodorescu <teo@flex.ro>
2000-02-16 22:13 ` Tom Lane <tgl@sss.pgh.pa.us>
2000-02-17 18:04 ` Constantin Teodorescu <teo@flex.ro>
2000-02-19 15:15 ` Hiroshi Inoue <Inoue@tpf.co.jp>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox