Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-20 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-11 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-09 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-09 Thread Tom Lane
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-09 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-09 Thread Tom Lane
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-08 Thread Josh Berkus
Tom, all, SELECT: currval UPDATE: nextval, setval USAGE: nextval, currval +1. --Josh ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-07 Thread Marko Kreen
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Marko Kreen
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Tom Lane
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
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,

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Marko Kreen
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Tom Lane
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruno Wolff III
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
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()?

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Marko Kreen
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()

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Marko Kreen
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Tom Lane
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Marko Kreen
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Marko Kreen
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Jaime Casanova
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Tom Lane
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Josh Berkus
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. Yet

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Tom Lane
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Marko Kreen
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
Marko Kreen wrote: 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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Tom Lane
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Tom Lane
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Tom Lane
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-06 Thread Tom Lane
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-05 Thread Bruce Momjian
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; ...

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-05 Thread Tom Lane
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-05 Thread Bruce Momjian
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-05 Thread Josh Berkus
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-05 Thread Neil Conway
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

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-05 Thread Tom Lane
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() ).

Re: [PATCHES] [HACKERS] Inconsistent syntax in GRANT

2006-01-05 Thread Bruno Wolff III
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