Re: [HACKERS] GRANT ON ALL IN schema

2009-10-12 Thread Tom Lane
Petr Jelinek pjmo...@pjmodos.net writes: [ latest GRANT ALL patch ] I started looking at this, and the first thing I noticed was that it adds TABLES, FUNCTIONS, and SEQUENCES as unreserved keywords. Now I'm not a fan of bloating the parser that way, but I have to admit that GRANT ON ALL TABLE

Re: [HACKERS] GRANT ON ALL IN schema

2009-10-12 Thread Jaime Casanova
On Mon, Oct 12, 2009 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote: ALTER DEFAULT PRIVILEGES ... GRANT ... ON TABLES TO ... this makes sense to me, because you want the default to affect all new tables not only a new single table. so, as someone once told, +1 from me ;) -- Atentamente,

Re: [HACKERS] GRANT ON ALL IN schema

2009-10-12 Thread Tom Lane
Petr Jelinek pjmo...@pjmodos.net writes: [ GRANT ON ALL ] Applied with minor editorialization (mainly changing some choices of identifiers) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] GRANT ON ALL IN schema

2009-10-12 Thread Tom Lane
Jaime Casanova jcasa...@systemguards.com.ec writes: On Mon, Oct 12, 2009 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote: ALTER DEFAULT PRIVILEGES ... GRANT ... ON TABLES TO ... this makes sense to me, because you want the default to affect all new tables not only a new single table. so, as

Re: [HACKERS] GRANT ON ALL IN schema

2009-10-12 Thread Brendan Jurd
2009/10/13 Tom Lane t...@sss.pgh.pa.us: I started looking at this, and the first thing I noticed was that it adds TABLES, FUNCTIONS, and SEQUENCES as unreserved keywords.  Now I'm not a fan of bloating the parser that way, but I have to admit that GRANT ON ALL TABLE IN SCHEMA wouldn't read

Re: [HACKERS] GRANT ON ALL IN schema

2009-10-10 Thread Jaime Casanova
On Sun, Sep 27, 2009 at 11:54 AM, Robert Haas robertmh...@gmail.com wrote: If this patch looks good now, can you mark it Ready for Committer in the CommitFest app?  If there are any remaining issues, please post a further review. while i'm not the reviewer this patch doesn't apply cleanly

Re: [HACKERS] GRANT ON ALL IN schema

2009-10-10 Thread Petr Jelinek
Jaime Casanova napsal(a): On Sun, Sep 27, 2009 at 11:54 AM, Robert Haas robertmh...@gmail.com wrote: If this patch looks good now, can you mark it Ready for Committer in the CommitFest app? If there are any remaining issues, please post a further review. while i'm not the reviewer

Re: [HACKERS] GRANT ON ALL IN schema

2009-09-28 Thread Abhijit Menon-Sen
At 2009-09-27 12:54:48 -0400, robertmh...@gmail.com wrote: If this patch looks good now, can you mark it Ready for Committer in the CommitFest app? Done. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] GRANT ON ALL IN schema

2009-09-27 Thread Robert Haas
2009/9/21 Petr Jelinek pjmo...@pjmodos.net: Abhijit Menon-Sen wrote: I have not yet been able to do a complete review of this patch, but I am posting this because I'll be travelling for a week starting tomorrow. My comments are based mostly on reading the patch, and not on any intensive

Re: [HACKERS] GRANT ON ALL IN schema

2009-09-27 Thread Petr Jelinek
Robert Haas napsal(a): Abhijit, If this patch looks good now, can you mark it Ready for Committer in the CommitFest app? If there are any remaining issues, please post a further review. I believe he'll be out for two more days. -- Regards Petr Jelinek (PJMODOS) -- Sent via

Re: [HACKERS] GRANT ON ALL IN schema

2009-09-21 Thread Petr Jelinek
Abhijit Menon-Sen wrote: I have not yet been able to do a complete review of this patch, but I am posting this because I'll be travelling for a week starting tomorrow. My comments are based mostly on reading the patch, and not on any intensive testing of the feature. I have left the patch status

Re: [HACKERS] GRANT ON ALL IN schema

2009-09-20 Thread Abhijit Menon-Sen
(This is a partial review of the grantonall-20090810v2.diff patch posted by Petr Jelinek on 2009-08-10 (hi PJMODOS!). See http://archives.postgresql.org/message-id/4a7f5853.5010...@pjmodos.net for the original message.) I have not yet been able to do a complete review of this patch, but I am

Re: [HACKERS] GRANT ON ALL IN schema

2009-09-20 Thread Abhijit Menon-Sen
At 2009-09-20 20:20:11 +0530, a...@toroid.org wrote: 1. The patch did apply to HEAD and build cleanly, but there are now a couple of minor (documentation) conflicts. To be more clear, what I meant is that it did apply and build cleanly when it was posted, but things have drifted enough now

Re: Anonymous code blocks (was: Re: [HACKERS] GRANT ON ALL IN schema)

2009-09-18 Thread Brendan Jurd
Hi Dimitri, The commitfest app has you listed as the reviewer for this patch. Any progress on your review? Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: Anonymous code blocks (was: Re: [HACKERS] GRANT ON ALL IN schema)

2009-09-18 Thread Dimitri Fontaine
Brendan Jurd dire...@gmail.com writes: The commitfest app has you listed as the reviewer for this patch. Any progress on your review? Funny I just sent a mail to rrr explaining I don't think I'll be able to complete my review until next Thursday. Feel free to steal me the patch if you want to,

Anonymous code blocks (was: Re: [HACKERS] GRANT ON ALL IN schema)

2009-08-28 Thread Petr Jelinek
The question is still valid, though it's better put in your words - do we want to refactor the existing compiler or write a separate one ? So, for now I went with the path of custom compiler and current executor. I attached current version of the patch. I don't expect this to get committed or

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-21 Thread Tom Lane
Alvaro Herrera alvhe...@commandprompt.com writes: Petr Jelinek wrote: The implementation as I see it would create function in pg_temp namespace, call it and then drop it. Any other implementation would imho mean rewriting procedure language api. That's really ugly. It'll cause catalog bloat

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-21 Thread Petr Jelinek
Tom Lane napsal(a): That's really ugly. It'll cause catalog bloat with every execution. I think it would be acceptable to have a new column in pg_language that pointed to an anonymous block execute function. Languages that do not define this function cannot use this new feature. +1.

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-21 Thread Tom Lane
Petr Jelinek pjmo...@pjmodos.net writes: However there is one question about implementing it in plpgsql. Currently, the compiler reads info directly from heap tuple, so I either have to write separate compiler for inline functions or change the existing one to accept the required info as

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-21 Thread Petr Jelinek
Tom Lane napsal(a): Petr Jelinek pjmo...@pjmodos.net writes: However there is one question about implementing it in plpgsql. Currently, the compiler reads info directly from heap tuple, so I either have to write separate compiler for inline functions or change the existing one to accept

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-20 Thread Petr Jelinek
Tom Lane napsal(a): Peter Eisentraut pete...@gmx.net writes: Well, I don't know if we really need to call it lambda, but I fully expect to be able to use these ad hoc functions as part of other expressions. Why would you expect that? To be used in an expression, you'd also need decoration to

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-20 Thread Alvaro Herrera
Petr Jelinek wrote: The implementation as I see it would create function in pg_temp namespace, call it and then drop it. Any other implementation would imho mean rewriting procedure language api. That's really ugly. It'll cause catalog bloat with every execution. I think it would be

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-16 Thread Peter Eisentraut
On sön, 2009-08-16 at 00:04 -0400, Andrew Dunstan wrote: SQL is not Lisp. Simple is good. I didn't think Peter was really very serious. Well, I don't know if we really need to call it lambda, but I fully expect to be able to use these ad hoc functions as part of other expressions. So making

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-16 Thread Pavel Stehule
2009/8/16 Peter Eisentraut pete...@gmx.net: On sön, 2009-08-16 at 00:04 -0400, Andrew Dunstan wrote: SQL is not Lisp. Simple is  good. I didn't think Peter was really very serious. Well, I don't know if we really need to call it lambda, but I fully expect to be able to use these ad hoc

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-16 Thread Sam Mason
On Sun, Aug 16, 2009 at 03:57:08PM +0300, Peter Eisentraut wrote: On 2009-08-16 at 00:04 -0400, Andrew Dunstan wrote: SQL is not Lisp. Simple is good. I didn't think Peter was really very serious. Well, I don't know if we really need to call it lambda, but I fully expect to be able to

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-16 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes: On sön, 2009-08-16 at 00:04 -0400, Andrew Dunstan wrote: SQL is not Lisp. Simple is good. I didn't think Peter was really very serious. Well, I don't know if we really need to call it lambda, but I fully expect to be able to use these ad hoc

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-16 Thread daveg
On Sat, Aug 15, 2009 at 11:34:04PM +0200, Dimitri Fontaine wrote: Nitpicking dept, I think I prefer: DO [ [LANGUAGE] language] $$ ... $$; DO plperl $$ ... $$; DO language plpython $$ ... $$; language is optional and defaults to plpgsql. +1 -dg -- David Gould da...@sonic.net

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-16 Thread daveg
On Sun, Aug 16, 2009 at 02:59:53PM +0200, Pavel Stehule wrote: 2009/8/16 Peter Eisentraut pete...@gmx.net: On sön, 2009-08-16 at 00:04 -0400, Andrew Dunstan wrote: SQL is not Lisp. Simple is  good. I didn't think Peter was really very serious. Well, I don't know if we really need to

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-15 Thread Dimitri Fontaine
Hi, Le 10 août 09 à 17:19, Andrew Dunstan a écrit : One fairly simple way would use a new SQL verb (say, DO) like this: DO $$ something in plfoo$ $ LANGUAGE plfoo; We could even default the langauge to plpgsql, for which you would then just need: DO $$ something in plpgsql $$; That

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-15 Thread Pavel Stehule
2009/8/15 Dimitri Fontaine dfonta...@hi-media.com: Hi, Le 10 août 09 à 17:19, Andrew Dunstan a écrit : One fairly simple way would use a new SQL verb (say, DO) like this: DO $$ something in plfoo$ $ LANGUAGE plfoo; We could even default the langauge to plpgsql, for which you would then

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-15 Thread Andrew Dunstan
Pavel Stehule wrote: why we need DO statement? Why not just $$ $$. Only string literal cannot be statement too, so DO is unnecessary. it can look like: $$ FOR r IN SELECT END LOOP; $$; ??? Well, it's arguably somewhat un-SQL-ish. Every command in SQL is introduced by a

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-15 Thread Pavel Stehule
2009/8/15 Andrew Dunstan and...@dunslane.net: Pavel Stehule wrote: why we need DO statement? Why not just $$ $$. Only string literal cannot be statement too, so DO is unnecessary. it can look like: $$  FOR r IN SELECT  END LOOP; $$; ??? Well, it's arguably somewhat

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-15 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: Pavel Stehule wrote: why we need DO statement? Why not just $$ $$. Only string literal cannot be statement too, so DO is unnecessary. I'm also not sure I want to be trying to execute any arbitrary string that accidentally gets placed there because

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-15 Thread Josh Berkus
I'm also not sure I want to be trying to execute any arbitrary string that accidentally gets placed there because someone forgot to put a keyword or accidentally deleted it. But I'm not too dogmatic on the subject. What do others think? Given that $$ is also used to quote non-procedural

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-15 Thread Dimitri Fontaine
Le 15 août 09 à 22:49, Josh Berkus a écrit : Ideally, we'd be able to execute *any* PL that way by setting a shell variable: \pl plperl DO $f$ foreach ( @_ ) { ... Nitpicking dept, I think I prefer: DO [ [LANGUAGE] language] $$ ... $$; DO plperl $$ ... $$; DO language plpython $$ ... $$;

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-15 Thread Sam Mason
On Sat, Aug 15, 2009 at 11:34:04PM +0200, Dimitri Fontaine wrote: Nitpicking dept, I think I prefer: DO [ [LANGUAGE] language] $$ ... $$; DO plperl $$ ... $$; DO language plpython $$ ... $$; language is optional and defaults to plpgsql. Yup, sounds nicer. The less globals the better!

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-15 Thread Andrew Dunstan
Josh Berkus wrote: I'm also not sure I want to be trying to execute any arbitrary string that accidentally gets placed there because someone forgot to put a keyword or accidentally deleted it. But I'm not too dogmatic on the subject. What do others think? Given that $$ is also used to

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-15 Thread Peter Eisentraut
On lör, 2009-08-15 at 23:31 +0100, Sam Mason wrote: On Sat, Aug 15, 2009 at 11:34:04PM +0200, Dimitri Fontaine wrote: Nitpicking dept, I think I prefer: DO [ [LANGUAGE] language] $$ ... $$; DO plperl $$ ... $$; DO language plpython $$ ... $$; language is optional and defaults

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-15 Thread Sam Mason
On Sun, Aug 16, 2009 at 02:15:39AM +0300, Peter Eisentraut wrote: On 2009-08-15 at 23:31 +0100, Sam Mason wrote: Next all you need is to be able to PREPARE them (and somehow access the parameters from execute) and you'll have nice local functions. :) Yeah, rather than just making up some

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-15 Thread Robert Haas
On Sat, Aug 15, 2009 at 7:15 PM, Peter Eisentrautpete...@gmx.net wrote: On lör, 2009-08-15 at 23:31 +0100, Sam Mason wrote: On Sat, Aug 15, 2009 at 11:34:04PM +0200, Dimitri Fontaine wrote: Nitpicking dept, I think I prefer:  DO [ [LANGUAGE] language] $$ ... $$;  DO plperl $$ ... $$;  

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-15 Thread Andrew Dunstan
Robert Haas wrote: I like this idea (although it might not be too easy to implement, not sure), but I think we could still use DO (which is shorter) for the verb. Lambda-calculus is cool, but do is nice and simple. SQL is not Lisp. Simple is good. I didn't think Peter was really very

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-10 Thread Peter Eisentraut
On Wednesday 05 August 2009 19:59:52 Tom Lane wrote: Or maybe we are going at this the wrong way? Would it be better to try harder to support the write-a-plpgsql-function approach? This would become much simpler if you could just execute plpgsql code instead of having to define a function

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-10 Thread Kevin Grittner
Peter Eisentraut pete...@gmx.net wrote: This would become much simpler if you could just execute plpgsql code instead of having to define a function around it. I have often wished for that feature. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-10 Thread Andrew Dunstan
Kevin Grittner wrote: Peter Eisentraut pete...@gmx.net wrote: This would become much simpler if you could just execute plpgsql code instead of having to define a function around it. I have often wished for that feature. You're not Robinson Crusoe. It could be done in

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-10 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes: One fairly simple way would use a new SQL verb (say, DO) like this: DO $$ something in plfoo $$ LANGUAGE plfoo; Yeah, this has been suggested before. I can't see anything very wrong with it. We could even default the langauge to plpgsql, for which

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-10 Thread Robert Haas
On Mon, Aug 10, 2009 at 11:36 AM, Tom Lanet...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: One fairly simple way would use a new SQL verb (say, DO) like this: DO $$ something in plfoo $$ LANGUAGE plfoo; Yeah, this has been suggested before.  I can't see anything very

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-10 Thread Pavel Stehule
2009/8/10 Robert Haas robertmh...@gmail.com: On Mon, Aug 10, 2009 at 11:36 AM, Tom Lanet...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: One fairly simple way would use a new SQL verb (say, DO) like this: DO $$ something in plfoo $$ LANGUAGE plfoo; Yeah, this has been

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-10 Thread Heikki Linnakangas
Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: But to make it really nice you'd have to move away from pl programs as strings. That would be a lot more work, and you really wouldn't want to make it work with more than one PL for the sake of everyone's sanity. You mean something

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-10 Thread Andrew Dunstan
Heikki Linnakangas wrote: Something like DO $$ begin ...; end $$; gives 90% of the usability with 10% of the trouble. Yes, I think that's the consensus. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-10 Thread Josh Berkus
Something like DO $$ begin ...; end $$; gives 90% of the usability with 10% of the trouble. I'd be a big fan of this. Especially if we could at an \e for it in psql. \ec? I'm not agreeing, though, that we don't need a GRANT ALL/ALTER DEFAULT. We still need that for the simplest cases so

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-10 Thread Stephen Frost
* Josh Berkus (j...@agliodbs.com) wrote: I'm not agreeing, though, that we don't need a GRANT ALL/ALTER DEFAULT. We still need that for the simplest cases so that novice-level users will use *some* access control. But it would mean that we wouldn't need GRANT ALL/ALTER DEFAULT to support

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-09 Thread Petr Jelinek
Josh Berkus wrote: I disagree here. While it's nice to be MySQL-compatible, a glob * is not at all consistent with other SQL syntax, whereas ALL and GRANT ON ALL IN SCHEMA schema are. The * was reaction to Toms fears of standard adding GRANT ON ALL with conflicting meaning, but I don't

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-09 Thread Petr Jelinek
Hi, I attached revised version of the patch. Changes, thoughts: - SCHEMA is mandatory now - removed VIEWS and GRANT ON VIEW since it looks like only me and Stephen want it there - the patch is now made so that adding new filters in the future won't mean tearing of half of the parser code and

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-09 Thread Petr Jelinek
Petr Jelinek wrote: I attached revised version of the patch. Changes, thoughts: - SCHEMA is mandatory now - removed VIEWS and GRANT ON VIEW since it looks like only me and Stephen want it there - the patch is now made so that adding new filters in the future won't mean tearing of half of the

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-08 Thread Josh Berkus
Well, since I've written the patch I am for it :) Probably with that GRANT ON * and GRANT ON schema.* as it has indeed very low probability that something like that will be in standard with different meaning and also it's mysql compatible (which is the only db currently having this feature I

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-07 Thread Richard Huxton
decibel wrote: In this specific case, I think there's enough demand to warrant a built-in mechanism for granting, but if something like exec() is built-in then the bar isn't as high for what the built-in GRANT mechanism needs to handle. CREATE OR REPLACE FUNCTION tools.exec( sql text

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-07 Thread Petr Jelinek
Stephen Frost wrote: As for changing the default ACL syntax to not be based around SCHEMA- I'm concerned that we'll then have to define some kind of ordering preference if we get away from the defaults being associated with the container object. If we have defaults for users and schemas, which

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-07 Thread Petr Jelinek
I am sorry I forgot to write my opinion on these. Do we want to differentiate views from tables in these commands or not ? I'd like to have views separate but I don't feel strongly about it. However having single statement for TABLE, VIEW and SEQUENCE is not a good idea IMHO, it will add

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-06 Thread Stephen Frost
* Andrew Dunstan (and...@dunslane.net) wrote: Tom Lane wrote: I'm not sure whether there is consensus on not using GRANT ON VIEW (ie, having these patches treat tables and views alike). I was waiting to see if Stephen would put forward a convincing counterargument ... Conceptually it is

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-06 Thread decibel
On Aug 5, 2009, at 11:59 AM, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: ... bulk-grant could be based on object type, object name (with wildcard or regexp pattern), schema membership, or maybe other things, and I think that would be quite useful if we can figure out how to make

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-06 Thread Pavel Stehule
\cmd grant select on * to user when I wrote epsql I implemented \fetchall metastatement. http://okbob.blogspot.com/2009/03/experimental-psql.html It's should be used for GRANT DECLARE x CURSOR FOR SELECT * FROM information_schema.tables \fetchall x GRANT ALL ON :table_name TO public;

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Robert Haas
On Mon, Jul 20, 2009 at 2:12 AM, Nikhil Sontakkenikhil.sonta...@enterprisedb.com wrote: The review is complete from my side. There is this question about consistency between this patch and the Defaultacls patch. But am ok with this patch on its own. So ready for committer from my side. My

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: My understanding is that this patch will need to be reworked as well based on Tom's comments on DefaultACLs. Does that sound right? Should we expect a new version this week, or defer this until the September CommitFest? I was planning to go review

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Andrew Dunstan
Tom Lane wrote: I'm not sure whether there is consensus on not using GRANT ON VIEW (ie, having these patches treat tables and views alike). I was waiting to see if Stephen would put forward a convincing counterargument ... Conceptually it is right, I think. A view is a virtual table,

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Robert Haas
On Wed, Aug 5, 2009 at 12:40 PM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: My understanding is that this patch will need to be reworked as well based on Tom's comments on DefaultACLs.  Does that sound right? Should we expect a new version this week, or defer

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: ... bulk-grant could be based on object type, object name (with wildcard or regexp pattern), schema membership, or maybe other things, and I think that would be quite useful if we can figure out how to make it clean and elegant. Yeah. In the end you

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Tom Lane
Petr Jelinek pjmo...@pjmodos.net writes: One more typo fix in docs I took a quick look at this version of the patch. Other than the already-mentioned question of whether we really want to create a distinction between tables and views in GRANT, there's not that much there to criticize. I do

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Petr Jelinek
Tom Lane wrote: I do have a feeling that the implementation is a bit too narrowly focused on the stuff IN SCHEMA foo case; if we were ever to add other filtering options it seems like we'd have to rip all this code out and start over. But I don't have any immediate ideas on what it should look

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Josh Berkus
Tom, I took a quick look at this version of the patch. Other than the already-mentioned question of whether we really want to create a distinction between tables and views in GRANT, there's not that much there to criticize. It's pretty common to have a database where there are some users

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Robert Haas
On Wed, Aug 5, 2009 at 2:57 PM, Josh Berkusj...@agliodbs.com wrote: Right now we have a situation where most web developers aren't using ROLEs *at all* because they are too complex for them to bother with.  I literally couldn't count the number of production applications I've run across which

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: I have one database that is set up with a reporting user (read only on everything). It requires constant maintenance. Every time an object is added or deleted (or dropped and recreated, like a view, which I do ALL THE TIME to work around the

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Robert Haas
On Wed, Aug 5, 2009 at 3:40 PM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: I have one database that is set up with a reporting user (read only on everything).  It requires constant maintenance.  Every time an object is added or deleted (or dropped and

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Pavel Stehule
2009/8/5 Tom Lane t...@sss.pgh.pa.us: Robert Haas robertmh...@gmail.com writes: I have one database that is set up with a reporting user (read only on everything).  It requires constant maintenance.  Every time an object is added or deleted (or dropped and recreated, like a view, which I do

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Josh Berkus
Josh's position that this should be standard SQL is nonsense, or at least he ought to be making that argument to the standards committee not us. Huh? When did I say that? If we want something built-in, maybe providing some prefab plpgsql functions is the way to go. But we'd have to

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Tom Lane
Josh Berkus j...@agliodbs.com writes: Josh's position that this should be standard SQL is nonsense, or at least he ought to be making that argument to the standards committee not us. Huh? When did I say that? Sorry, I think I got one of your messages confused with one of Robert's. Anyway,

Re: [HACKERS] GRANT ON ALL IN schema

2009-08-05 Thread Robert Haas
On Aug 5, 2009, at 4:55 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Berkus j...@agliodbs.com writes: Josh's position that this should be standard SQL is nonsense, or at least he ought to be making that argument to the standards committee not us. Huh? When did I say that? Sorry, I

Re: [HACKERS] GRANT ON ALL IN schema

2009-07-20 Thread Nikhil Sontakke
Hi, Nikhil, This is still flagged as Needs Review.  Are you still reviewing the latest version, or should this be set to ready for committer, or what? The review is complete from my side. There is this question about consistency between this patch and the Defaultacls patch. But am ok with

Re: [HACKERS] GRANT ON ALL IN schema

2009-07-19 Thread Robert Haas
On Fri, Jul 17, 2009 at 9:16 AM, Petr Jelinekpjmo...@pjmodos.net wrote: One more typo fix in docs -- Regards Petr Jelinek (PJMODOS) Nikhil, This is still flagged as Needs Review. Are you still reviewing the latest version, or should this be set to ready for committer, or what? ...Robert

Re: [HACKERS] GRANT ON ALL IN schema

2009-07-17 Thread Nikhil Sontakke
Hi, Attached is v2 with slightly improved code, nothing has changed feature-wise. Here are some comments on this patch from my side: grant.sgml * Maybe we should use replaceable class=parameterschemaname/replaceable in the sgml references instead of just replaceableschemaname/replaceable

Re: [HACKERS] GRANT ON ALL IN schema

2009-07-17 Thread Petr Jelinek
Nikhil Sontakke wrote: grant.sgml * Maybe we should use replaceable class=parameterschemaname/replaceable in the sgml references instead of just replaceableschemaname/replaceable +There is also the posibility of granting permissions to all objects of +given type inside one or multiple

Re: [HACKERS] GRANT ON ALL IN schema

2009-07-17 Thread Petr Jelinek
One more typo fix in docs -- Regards Petr Jelinek (PJMODOS) diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml index bf963b8..6400f9e 100644 *** a/doc/src/sgml/ref/grant.sgml --- b/doc/src/sgml/ref/grant.sgml *** PostgreSQL documentation *** 23,39 synopsis

Re: [HACKERS] GRANT ON ALL IN schema

2009-07-07 Thread Simon Riggs
On Fri, 2009-07-03 at 12:44 +0200, Petr Jelinek wrote: Petr Jelinek wrote: So, here is the first version of the patch. Attached is v2 with slightly improved code, nothing has changed feature-wise. I would like to see GRANT ... ON ALL OBJECTS ... because I know that I will forget to do

Re: [HACKERS] GRANT ON ALL IN schema

2009-07-07 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes: I would like to see GRANT ... ON ALL OBJECTS ... This seems inherently broken, since different types of objects will have different grantable privileges. (I'm sure we can do something intelligent with privileges that don't apply to all object types

Re: [HACKERS] GRANT ON ALL IN schema

2009-07-07 Thread Greg Stark
On Tue, Jul 7, 2009 at 4:16 PM, Tom Lanet...@sss.pgh.pa.us wrote: (I'm sure we can do something intelligent with privileges that don't apply to all object types rather than just fail. e.g. UPDATE privilege should be same as USAGE on a sequence.) Anything you do in that line will be an ugly

Re: [HACKERS] GRANT ON ALL IN schema

2009-07-07 Thread Simon Riggs
On Tue, 2009-07-07 at 11:16 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: I would like to see GRANT ... ON ALL OBJECTS ... This seems inherently broken, since different types of objects will have different grantable privileges. (I'm sure we can do something

Re: [HACKERS] GRANT ON ALL IN schema

2009-07-03 Thread Petr Jelinek
Petr Jelinek wrote: So, here is the first version of the patch. Attached is v2 with slightly improved code, nothing has changed feature-wise. -- Regards Petr Jelinek (PJMODOS) diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml index bf963b8..7ddbd25 100644 ***

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-18 Thread Peter Eisentraut
On Wednesday 17 June 2009 20:27:20 Robert Haas wrote: What to do about wildcards is a stickier wicket, and maybe we need to decide that first, but I really don't think we should be discouraging anyone from investigating this stuff and trying to come up with good solutions. There will always

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-18 Thread Bernd Helmle
--On Mittwoch, Juni 17, 2009 16:44:53 +0300 Peter Eisentraut pete...@gmx.net wrote: I think you should design this with a bit wider scope. Instead of just all tables in this schema, think all tables satisfying some condition. It has been requested, for example, to be able to grant on all

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-17 Thread Petr Jelinek
So, here is the first version of the patch. It includes functionality itself, simple regression test and also very simple documentation. The patch allows GRANT ON ALL TABLES/VIEWS/FUNCTIONS/SEQUENCES IN schemaname, schemaname2 TO username and same thing for REVOKE. Words TABLES, VIEWS,

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-17 Thread Peter Eisentraut
On Wednesday 17 June 2009 11:29:10 Petr Jelinek wrote: The patch allows GRANT ON ALL TABLES/VIEWS/FUNCTIONS/SEQUENCES IN schemaname, schemaname2 TO username and same thing for REVOKE. Words TABLES, VIEWS, FUNCTIONS and SEQUENCES were added as unreserved keywords. Unfortunately I was unable to

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-17 Thread Stephen Frost
Peter, * Peter Eisentraut (pete...@gmx.net) wrote: Also since this patch introduces VIEWS as object with grantable privileges, I added GRANT ON VIEW foo syntax which is more or less synonymous to GRANT ON TABLE foo syntax. It felt weird to have GRANT ON ALL VIEWS but not GRANT ON VIEW.

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-17 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes: I think you should design this with a bit wider scope. Instead of just all tables in this schema, think all tables satisfying some condition. It has been requested, for example, to be able to grant on all tables that match a pattern. I'm against

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-17 Thread Stephen Frost
Petr, * Petr Jelinek (pjmo...@pjmodos.net) wrote: So, here is the first version of the patch. Neat, thanks! Some initial comments: You should read through this: http://wiki.postgresql.org/wiki/Submitting_a_Patch First big thing is that the patch should be a context diff. I would also

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-17 Thread Petr Jelinek
Stephen Frost wrote: I don't like the idea that a 'GRANT ALL' would actually change default ACLs for a schema though. These are two separate and distinct things- one is implementing a change to existing objects, the other is setting a default for new objects. Mixing them would lead to

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-17 Thread Petr Jelinek
Stephen Frost wrote: http://wiki.postgresql.org/wiki/Submitting_a_Patch First big thing is that the patch should be a context diff. I would It is context diff, at least I think so, I followed the instructions on wiki on how to make context patch from git repo. also recommend you put it

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-17 Thread Stephen Frost
* Petr Jelinek (pjmo...@pjmodos.net) wrote: Stephen Frost wrote: I don't like the idea that a 'GRANT ALL' would actually change default ACLs for a schema though. These are two separate and distinct things- one is implementing a change to existing objects, the other is setting a default for

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-17 Thread Peter Eisentraut
On Wednesday 17 June 2009 17:15:04 Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: I think you should design this with a bit wider scope. Instead of just all tables in this schema, think all tables satisfying some condition. It has been requested, for example, to be able to grant

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-17 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes: Why don't we tell people to write a plpgsql loop for the schema.* case as well? Indeed, why not? This all seems much more like gilding the lily than delivering useful new capability. The default-ACL stuff that Stephen is working on seems far more

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-17 Thread Stephen Frost
* Petr Jelinek (pjmo...@pjmodos.net) wrote: It is context diff, at least I think so, I followed the instructions on wiki on how to make context patch from git repo. err, sorry, tbh I just looked at the 'diff --git' line and didn't see any '-c'.. Trying to do too much at one time, I'm afraid.

Re: [HACKERS] GRANT ON ALL IN schema

2009-06-17 Thread Petr Jelinek
Peter Eisentraut wrote: I think you should design this with a bit wider scope. Instead of just all tables in this schema, think all tables satisfying some condition. It has been requested, for example, to be able to grant on all tables that match a pattern. Well, that's certainly possible

  1   2   >