On Wed, Oct 30, 2002 at 14:03:21 -0600,
>
> While I am not sure about triggers, it certainly is possible to get
> a similar effect be having the referenced function run with the security
> of the definer.
I read some more on triggers and found that according to the documentation,
they appear to r
On Wed, Oct 30, 2002 at 08:27:37 -0600,
Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> Do default expressions execute with access of the user doing the insert
> or the owner of the table?
> What I was thinking was that the owner of a table may want to allow people
> to do inserts into a table and u
I think we open up more security problems by having the inserter doing
things as the owner of the table.
---
Bruno Wolff III wrote:
> On Wed, Oct 30, 2002 at 14:03:21 -0600,
> >
> > While I am not sure about triggers, it ce
I said:
> And I have not yet been able to think of a concrete case where the
> existing behavior (execute as calling user) is better.
Okay, I've thought of one: consider the situation where you want to
label each row in a table with the ID of the user who inserted it.
Right now, you can do
On Sat, Nov 02, 2002 at 01:01:11 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> The example of a serial column (DEFAULT nextval('foo_seq')) seems
> compelling. You do not really want to grant general-purpose UPDATE
> rights on foo_seq to everyone you might allow to INSERT into your
> table.
If
On Fri, Nov 01, 2002 at 21:35:40 -0500,
Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> I think we open up more security problems by having the inserter doing
> things as the owner of the table.
With triggers it is a bit hard to decide. Since people other than the
table owner can create them, but
The problem is that the more complex you make things, the easier it is
to make a mistake. That's why I like our simpler model unless there is
a glaring problem with it.
---
Bruno Wolff III wrote:
> On Fri, Nov 01, 2002 at 2
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The problem is that the more complex you make things, the easier it is
> to make a mistake. That's why I like our simpler model unless there is
> a glaring problem with it.
I think Bruno's got a good point. The implementation would be kind of
painful,
Tom Lane writes:
> Okay, I've thought of one: consider the situation where you want to
> label each row in a table with the ID of the user who inserted it.
> Right now, you can do
> ...,
> who namedefault current_user,
> ...
> or for greater security use a trigger to set