"John Gray" <[EMAIL PROTECTED]> writes:
> Firstly, I appreciate this may be a hare-brained scheme, but I've been
> thinking about indexes in which the tuple pointer is not unique.
It sounds pretty hare-brained to me all right ;-). What's wrong with
the normal approach of one index tuple per heap
I updated the patch to use the SET AUTHORIZATION { INVOKER | DEFINER }
terminology. Also, the function owner is now determined and saved at compile
time (no gotchas here, right?). It is located at
http://volpe.home.mindspring.com/pgsql/set_auth.patch
Mark
---(end of broa
> > I am not sure whether the feature does not actually present a security
> > hole ? Two collaborating users can pass each other their privileges.
>
> I don't see any (new) security risk here. Code written by one user can
> be executed with the privileges of another --- so what? That's the
>
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Without making the "definer" need an additional grant for creating such
> a function, it would be like giving him all the privs he has
> "with grant option".
Hmm ... interesting analogy, but does it hold water? The GRANT OPTION
stuff implie
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> I am not sure whether the feature does not actually present a security
> hole ? Two collaborating users can pass each other their privileges.
I don't see any (new) security risk here. Code written by one user can
be executed with the privile
> > Anybody else want to object to this abbreviation idea ?
>
> I thought we already agreed to change the names per Peter's suggestion.
>
> I didn't like the original names whether abbreviated or not ...
Good. I have not seen that agreement, maybe it was implied.
I am not sure whether the feat
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Anybody else want to object to this abbreviation idea ?
I thought we already agreed to change the names per Peter's suggestion.
I didn't like the original names whether abbreviated or not ...
regards, tom lane
--
Actually, I liked the SET AUTHORIZATION { DEFINER | INVOKER } terminology
mentioned earlier.
Mark
Zeugswetter Andreas SB wrote:
>
> > > This patch will implement the "ENABLE PRIVILEGE" and "DISABLE PRIVILEGE"
> > > commands in PL/pgSQL, which, respectively, change the effective uid to that
>
> > Still, it's an interesting alternative. Comments anyone?
>
> SelfExclusiveLock is clear and can't be confused with other
> lock types.
How about giving it a label ? SelfExclusive would somehow suggest,
that you can have more than one self exclusive lock.
Like:
lock table atab in s
> > This patch will implement the "ENABLE PRIVILEGE" and "DISABLE PRIVILEGE"
> > commands in PL/pgSQL, which, respectively, change the effective uid to that
> > of the function owner and back. It doesn't break security (I hope). The
> > commands can be abbreviated as "ENABLE" and "DISABLE" for
10 matches
Mail list logo
