Updated patch applied. I decided Tom was right to just ignore invalid
sequence permission from pre-8.2 databases, rather than try to use GRANT
TABLE; there was no reason to do it and avoiding it made the code
cleaner and more robust.
The changes were:
Add GRANT ON SEQUENCE syntax to support se
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Just ignore the inapplicable permissions during pg_dump. I think you're
> >> making this harder than it needs to be...
>
> > check all permission bits
> > call object-type-specific routine
> > loop over each obj
Bruce Momjian writes:
> Tom Lane wrote:
>> Just ignore the inapplicable permissions during pg_dump. I think you're
>> making this harder than it needs to be...
> I don't think we should allow GRANT DELETE ON seq in 8.2 for invalid
> permission.
That's fine, but pg_dump has to continue to work a
Tom Lane wrote:
> Bruce Momjian writes:
> > At first I was just going to continue allowing table-like permissions
> > for sequences if a GRANT [TABLE] was used, and add the new
> > USAGE/SELECT/UPDATE capability only for GRANT SEQUENCE. The problem was
> > that you could create a non-dumpable per
Bruce Momjian writes:
> At first I was just going to continue allowing table-like permissions
> for sequences if a GRANT [TABLE] was used, and add the new
> USAGE/SELECT/UPDATE capability only for GRANT SEQUENCE. The problem was
> that you could create a non-dumpable permission setup if you added
Bruce Momjian wrote:
> Tom Lane wrote:
> > I wrote:
> > > Bruce Momjian writes:
> > >> Does the standard require USAGE to support currval?
> >
> > > currval isn't in the standard (unless I missed something), so it has
> > > nothing to say one way or the other on the point.
> >
> > Wait, I take t
Tom, all,
SELECT: currval
UPDATE: nextval, setval
USAGE: nextval, currval
+1.
--Josh
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On 1/7/06, Bruce Momjian wrote:
> Marko Kreen wrote:
> > The above table seem bit messy, but I see it as much easier to explain
> > to somebody.
>
> I am confused about your list above, so I can't see how that would be
> easy to explain.
Easy as in "use GRANT USAGE, forget about rest". You are c
Bruce Momjian writes:
> Should UPDATE also allow currval()? Your logic below seems to suggest
> that.
I thought about that, but there are a couple of reasons not to:
1. It'd be a change from the current behavior of UPDATE privilege.
2. If there's someone out there who really does want write-onl
Tom Lane wrote:
> I wrote:
> > Bruce Momjian writes:
> >> Does the standard require USAGE to support currval?
>
> > currval isn't in the standard (unless I missed something), so it has
> > nothing to say one way or the other on the point.
>
> Wait, I take that back. Remember our previous discus
Should UPDATE also allow currval()? Your logic below seems to suggest
that.
---
Tom Lane wrote:
> I wrote:
> > Bruce Momjian writes:
> >> Does the standard require USAGE to support currval?
>
> > currval isn't in the stan
I wrote:
> Bruce Momjian writes:
>> Does the standard require USAGE to support currval?
> currval isn't in the standard (unless I missed something), so it has
> nothing to say one way or the other on the point.
Wait, I take that back. Remember our previous discussions about this
point: the spec
Bruce Momjian writes:
> Does the standard require USAGE to support currval?
currval isn't in the standard (unless I missed something), so it has
nothing to say one way or the other on the point.
Basically what we seem to be homing in on is to keep SELECT and UPDATE
privileges doing what they do
Tom Lane wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > Good point about compatibility. But makes the common case ugly.
> > "For regular usage you need to grant SELECT, USAGE ..." Huh? :)
>
> > How about this:
>
> > SELECT: currval
> > INSERT: nextval
> > UPDATE: nextval, setval
> > USAGE
Marko Kreen <[EMAIL PROTECTED]> writes:
> Good point about compatibility. But makes the common case ugly.
> "For regular usage you need to grant SELECT, USAGE ..." Huh? :)
> How about this:
> SELECT: currval
> INSERT: nextval
> UPDATE: nextval, setval
> USAGE: nextval, currval
Seems a little w
Marko Kreen wrote:
> On 1/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Bruce Momjian writes:
> > > FYI, we could support USAGE just on sequences, and have it map to
> > > UPDATE, but pg_dump it out as USAGE.
> >
> > It seems the spec doesn't cover setval() and currval(), which is not
> > too surp
On 1/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruce Momjian writes:
> > FYI, we could support USAGE just on sequences, and have it map to
> > UPDATE, but pg_dump it out as USAGE.
>
> It seems the spec doesn't cover setval() and currval(), which is not
> too surprising given those aren't standar
Josh Berkus writes:
>> BTW, what about lastval()?
> Overal, it's hard to get too concerned about this, since a user can't
> really get anything out of lastval() if he doesn't have permissions on the
> sequence he's trying to query, in order to run currval.
Well, no, consider my example to Mark
Tom,
> BTW, what about lastval()? I'm not sure we can usefully associate any
> privilege check with that, since it's not clear which sequence it
> applies to. Does it make sense to remember what sequence the value came
> from and privilege-check against that, or is that just too weird?
Hmmm. Y
Bruce Momjian writes:
> FYI, we could support USAGE just on sequences, and have it map to
> UPDATE, but pg_dump it out as USAGE.
It seems the spec doesn't cover setval() and currval(), which is not
too surprising given those aren't standard.
Here is a proposal:
SELECT priv -> allows currval() a
Marko Kreen wrote:
> On 1/6/06, Bruce Momjian 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
On 1/6/06, Bruce Momjian wrote:
> Jaime Casanova wrote:
> > On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > > Marko Kreen <[EMAIL PROTECTED]> writes:
> > > > But my question is rather - is there any scenario where setval() should
> > > > go with nextval()?
> > >
> > > > It seems that their pair
On 1/6/06, Bruce Momjian 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
Jaime Casanova wrote:
> On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Marko Kreen <[EMAIL PROTECTED]> writes:
> > > But my question is rather - is there any scenario where setval() should
> > > go with nextval()?
> >
> > > It seems that their pairing is an accident and should be fixed.
> >
> >
Marko Kreen wrote:
> > In any case I think we are wasting our time discussing it, and instead
> > should be looking through the SQL2003 spec to see what it requires.
> > Bruce couldn't find anything in it about this but I can't believe the
> > info isn't there somewhere.
>
> Google tells that Orac
On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > But my question is rather - is there any scenario where setval() should
> > go with nextval()?
>
> > It seems that their pairing is an accident and should be fixed.
>
> I think the original argument for the
Tom Lane wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > But my question is rather - is there any scenario where setval() should
> > go with nextval()?
>
> > It seems that their pairing is an accident and should be fixed.
>
> I think the original argument for the current design was that with
Bruce Momjian wrote:
> > I'm not sure offhand what keywords we'd want to use, but now is the time
> > to look at it, *before* it becomes set in stone that GRANT ON SEQUENCE
> > is just another spelling of GRANT ON TABLE.
>
> Sequences do not support INSERT, UPDATE, or DELETE, but we overload
> UPD
Marko Kreen <[EMAIL PROTECTED]> writes:
> But my question is rather - is there any scenario where setval() should
> go with nextval()?
> It seems that their pairing is an accident and should be fixed.
I think the original argument for the current design was that with
enough nextval's you can dupl
On 1/6/06, Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 06, 2006 at 19:11:27 +0200,
> Marko Kreen <[EMAIL PROTECTED]> wrote:
> > On 1/6/06, Bruce Momjian wrote:
> >
> > Considering there's no currval() without nextval(), what point
> > is disallowing currval() when user is able to ca
On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> > On 1/6/06, Bruce Momjian wrote:
> >> Uh, logically, yes, but practially currval just reads/SELECTs, while
> >> nextval modifies/UPDATEs.
>
> > Yeah, thats the mechanics behind it, but the currval() only
>
Bruno Wolff III wrote:
> On Fri, Jan 06, 2006 at 19:11:27 +0200,
> Marko Kreen <[EMAIL PROTECTED]> wrote:
> > On 1/6/06, Bruce Momjian wrote:
> >
> > Considering there's no currval() without nextval(), what point
> > is disallowing currval() when user is able to call nextval()?
> >
> > I rathe
On Fri, Jan 06, 2006 at 19:11:27 +0200,
Marko Kreen <[EMAIL PROTECTED]> wrote:
> On 1/6/06, Bruce Momjian wrote:
>
> Considering there's no currval() without nextval(), what point
> is disallowing currval() when user is able to call nextval()?
>
> I rather want to allow nextval/currval and dis
Marko Kreen <[EMAIL PROTECTED]> writes:
> On 1/6/06, Bruce Momjian wrote:
>> Uh, logically, yes, but practially currval just reads/SELECTs, while
>> nextval modifies/UPDATEs.
> Yeah, thats the mechanics behind it, but the currval() only
> works if the user was already able to call nextval(), so I
On 1/6/06, Bruce Momjian wrote:
> Marko Kreen wrote:
> > On 1/6/06, Bruce Momjian wrote:
> > > Bruno Wolff III wrote:
> > > > It might be nice to split nextval and currval access as well. nextval
> > > > access
> > > > corresponds to INSERT and currval access to SELECT.
> > >
> > > Uh, that is a
Tom Lane wrote:
> Bruce Momjian writes:
> > FYI, SQL03 defines GRANT SEQUENCE.
>
> Oh. Well, then that gives us precedent to go by. What do they specify
> as the privileges for sequences?
They don't seem to specify which actions go with which objects in the
GRANT statement, nor do they specify
Marko Kreen wrote:
> On 1/6/06, Bruce Momjian wrote:
> > Bruno Wolff III wrote:
> > > It might be nice to split nextval and currval access as well. nextval
> > > access
> > > corresponds to INSERT and currval access to SELECT.
> >
> > Uh, that is already in the code. nextval()/setval() is UPDATE
Bruce Momjian writes:
> FYI, SQL03 defines GRANT SEQUENCE.
Oh. Well, then that gives us precedent to go by. What do they specify
as the privileges for sequences?
regards, tom lane
---(end of broadcast)---
TIP 9: In versio
Tom Lane wrote:
> Josh Berkus writes:
> >> Uh, how are they different? You mean just UPDATE and none of the
> >> others do anything?
>
> > Yes, it would be nice to have real permissions for sequences, specifically
> > USE (which allows nextval() and currval()) and UPDATE (which would allow
>
On 1/6/06, Bruce Momjian wrote:
> Bruno Wolff III wrote:
> > It might be nice to split nextval and currval access as well. nextval access
> > corresponds to INSERT and currval access to SELECT.
>
> Uh, that is already in the code. nextval()/setval() is UPDATE, and
> currval() is SELECT.
This see
Bruno Wolff III wrote:
> On Thu, Jan 05, 2006 at 11:44:24 -0800,
> Josh Berkus wrote:
> > Bruce, Tom,
> >
> > > > The permissions for a sequence aren't the same as they are for a
> > > > table. We've sort of ignored the point to date, but if we're going to
> > > > add special syntax for grantin
On Thu, Jan 05, 2006 at 11:44:24 -0800,
Josh Berkus wrote:
> Bruce, Tom,
>
> > > The permissions for a sequence aren't the same as they are for a
> > > table. We've sort of ignored the point to date, but if we're going to
> > > add special syntax for granting on a sequence, I don't think we sho
Josh Berkus writes:
>> Uh, how are they different? You mean just UPDATE and none of the
>> others do anything?
> Yes, it would be nice to have real permissions for sequences, specifically
> USE (which allows nextval() and currval()) and UPDATE (which would allow
> setval() ). However, I don
Bruce Momjian wrote:
The following patch allows VIEW and SEQUENCE for GRANT. I didn't add
checks for relkind, figuring it wasn't worth it, right?
I think checking the relkind is pretty reasonable, and should require
only a few lines of code -- why not do it?
-Neil
Bruce, Tom,
> > The permissions for a sequence aren't the same as they are for a
> > table. We've sort of ignored the point to date, but if we're going to
> > add special syntax for granting on a sequence, I don't think we should
> > continue to ignore it.
>
> Uh, how are they different? You mea
Tom Lane wrote:
> Bruce Momjian writes:
> > The following patch allows VIEW and SEQUENCE for GRANT. I didn't add
> > checks for relkind, figuring it wasn't worth it, right?
>
> The permissions for a sequence aren't the same as they are for a table.
> We've sort of ignored the point to date, but
Bruce Momjian writes:
> The following patch allows VIEW and SEQUENCE for GRANT. I didn't add
> checks for relkind, figuring it wasn't worth it, right?
The permissions for a sequence aren't the same as they are for a table.
We've sort of ignored the point to date, but if we're going to add
specia
Josh Berkus wrote:
> Folks,
>
> Just got tripped up by this:
>
> GRANT SELECT ON table1 TO someuser;
> GRANT SELECT ON table1_id_seq TO someuser;
> both work
>
> However,
> GRANT SELECT ON TABLE table1 TO someuser;
> ... works, while
> GRANT SELECT ON SEQUENCE table1_id_seq TO someuse
48 matches
Mail list logo
