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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian wrote:
Tom Lane wrote:
I wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian pgman@candle.pha.pa.us 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
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 pgman@candle.pha.pa.us 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
Bruno Wolff III wrote:
On Thu, Jan 05, 2006 at 11:44:24 -0800,
Josh Berkus josh@agliodbs.com 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
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Josh Berkus josh@agliodbs.com 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
Bruce Momjian pgman@candle.pha.pa.us 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
Marko Kreen wrote:
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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,
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us wrote:
Marko Kreen wrote:
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
Marko Kreen [EMAIL PROTECTED] writes:
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
On Fri, Jan 06, 2006 at 19:11:27 +0200,
Marko Kreen [EMAIL PROTECTED] wrote:
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
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 pgman@candle.pha.pa.us wrote:
Considering there's no currval() without nextval(), what point
is disallowing currval() when user is able to call nextval()?
On 1/6/06, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us wrote:
Uh, logically, yes, but practially currval just reads/SELECTs, while
nextval modifies/UPDATEs.
Yeah, thats the mechanics behind it, but the currval()
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 pgman@candle.pha.pa.us wrote:
Considering there's no currval() without nextval(), what point
is disallowing currval() when user is
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
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
UPDATE to
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
enough
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 current
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 Oracle has
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.
I think the original
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
On 1/6/06, Bruce Momjian pgman@candle.pha.pa.us 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
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
Bruce Momjian pgman@candle.pha.pa.us 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
Josh Berkus josh@agliodbs.com 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
On 1/7/06, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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 weird. Hmm
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: nextval, currval
Bruce Momjian pgman@candle.pha.pa.us 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
I wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Should UPDATE also allow currval()? Your logic below seems to suggest
that.
---
Tom Lane wrote:
I wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Does the standard require USAGE to support currval?
currval
Tom Lane wrote:
I wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian pgman@candle.pha.pa.us 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
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 someuser;
...
Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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 mean just
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
Josh Berkus josh@agliodbs.com 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() ).
On Thu, Jan 05, 2006 at 11:44:24 -0800,
Josh Berkus josh@agliodbs.com 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
46 matches
Mail list logo
