Re: Is a SERIAL column a "black box", or not?

[mark(at)mark(dot)mielke(dot)cc]

On Sun, Apr 30, 2006 at 01:42:37PM +0300, Hannu Krosing wrote:
> Ühel kenal päeval, L, 2006-04-29 kell 19:41, kirjutas
> mark(at)mark(dot)mielke(dot)cc:
> > On Sat, Apr 29, 2006 at 05:54:19PM -0400, Tom Lane wrote:
> > > In short, I think there's a reasonably good case to be made for losing the
> > > hidden dependency and re-adopting the viewpoint that saying SERIAL is
> > > *exactly* the same as making a sequence and then making a default
> > > expression that uses the sequence.  Nothing behind the curtain.
> > > 
> > > Comments, other opinions?
> > I find it user-unfriendly that I must grant select/update to the
> > SERIAL, separate than from the table. I don't really see anything
> > friendly about treating the object as separate.
> just define nextval() as SECURITY DEFINER 

If I understand correctly - I think that hides the problem, rather
than solving it. :-)

Shouldn't the SERIAL have the same permissions as the TABLE in the
general case? SECURITY DEFINER would give everybody full access?

> > I do see the benefits with regard to simplified implementation, and
> > flexibility.
> > As a compromise, I could see either choice being correct. I don't
> > see either direction as being both user friendly and simple.
> You can be user friendly and simple only if the user wants to do simple
> things, or if you can exactly predict what a user wants, else you have
> to grant some power to the user, and that involves complexity or at
> least a learning curve.

Yes.

Cheers,
mark

-- 
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/