Re: [HACKERS] Inconsistent syntax in GRANT - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: [HACKERS] Inconsistent syntax in GRANT
Date
Msg-id 200601062232.k06MWeu26590@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Inconsistent syntax in GRANT  (Marko Kreen <markokr@gmail.com>)
Responses Re: [HACKERS] Inconsistent syntax in GRANT
List pgsql-patches
Marko Kreen wrote:
> On 1/6/06, Bruce Momjian <pgman@candle.pha.pa.us> wrote:
> > Marko Kreen wrote:
> > > I found SQL2003 pdf's too ... from my reading it has only USAGE.
> > >
> > > 5WD-02-Foundation-2003-09.pdf:
> > > page 724 -> General Rules -> #2
> > > page 740 -> Syntax rules -> #3
> >
> > I admit I am terrible at understanding the standard, but I can't find
> > anything relevant on the page numbers you mentioned.  Are those the
> > document pages or the page numbers displayed by the PDF viewer?  What is
> > the section heading?  I am using the same filename you have.
>
> Those are print page numbers.  (In case you have dead-tree variant :)
> And I got them here: http://www.wiscorp.com/SQLStandards.html
>
> Uh, and they are bit wrong.  Ok here are they fully:
>
> 11.62 <sequence generator definition>
>   General rules (page 727 printed/751 real) point #2
>
> 12.3 <privileges>
>   Syntax rules (page 740 printed/764 real) point #3

OK, I see it now, and in an earlier email I quoted the part where I
think USAGE links in to nextval().  I was looking for something obvious. :-)

> > > Everything combined:
> > > SELECT: currval
> > > UPDATE: nextval
> > > USAGE: currval, nextval
> > > ALTER: setval
> > >
> > > Confusing?
> >
> > I see USAGE in the standard, but not ALTER.  We don't support USAGE so I
> > am guessing our SELECT/UPDATE behavior is OK.
>
> No, we still want to separate setval from nextval.

My point was that currval -> SELECT and nextval -> UPDATE was correct.
I see now that I am wrong and that the standard wants USAGE.

That combined was every db's behavior combined, right?  I got confused.

> > Does this mean we should
> > only allow owners to do setval(), rather than binding it to INSERT?
>
> My first reaction is that it should be grantable, although
> I can't find any reasons for it, except backwards compatibility.
>
> How about this:
>
> SELECT: currval
> INSERT: nextval
> USAGE: currval, nextval
> UPDATE: setval

I think nextval() is naturally UPDATE.  I am thinking setval would be
INSERT, and with setval() being used less, it would perhaps be a better
choice for a change anyway.

However, in doing the pg_dump part of the patch, I perhaps see a
problem.  If someone does:

    GRANT UPDATE ON seq1 TO PUBLIC;

do we give them nextval() and setval() permissions?  If they do:

    GRANT UPDATE ON SEQUENCE seq1 TO PUBLIC;
                    --------

they only set nextval()?  That seems quite confusing.  Can we change
UPDATE for both GRANT syntaxes, and somehow have people fix them up
after they load in 8.2?  How many non-owners do setval()?

FYI, we could support USAGE just on sequences, and have it map to
UPDATE, but pg_dump it out as USAGE.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-patches by date:

Previous
From: Jaime Casanova
Date:
Subject: Re: [HACKERS] Inconsistent syntax in GRANT
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Inconsistent syntax in GRANT