2009/10/13 Tom Lane :
> 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 well. What I am
Jaime Casanova writes:
> On Mon, Oct 12, 2009 at 1:42 PM, Tom Lane 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 ;)
Done.
Petr Jelinek 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:
http://www.postgresql.
On Mon, Oct 12, 2009 at 1:42 PM, Tom Lane 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,
Jaime Casanova
Sopor
Petr Jelinek 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 IN SCHEMA" wouldn't
Jaime Casanova napsal(a):
On Sun, Sep 27, 2009 at 11:54 AM, Robert Haas 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 appl
On Sun, Sep 27, 2009 at 11:54 AM, Robert Haas 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 anymore...
some co
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:
http://www.postgresq
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 pgsql-hackers
2009/9/21 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 fea
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
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 no
(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
posti
Brendan Jurd 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, as I'm planning
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
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 a
Tom Lane napsal(a):
Petr Jelinek 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 p
Petr Jelinek 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 parameters and "fa
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. The
Alvaro Herrera 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 with every executi
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 accept
Tom Lane napsal(a):
Peter Eisentraut 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 tell the fu
On Sun, Aug 16, 2009 at 02:59:53PM +0200, Pavel Stehule wrote:
> 2009/8/16 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 i
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...@soni
Peter Eisentraut 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 functions" a
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
2009/8/16 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"
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 ma
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 ver
On Sat, Aug 15, 2009 at 7:15 PM, Peter Eisentraut 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 $$ ... $$;
>> >
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
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
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 q
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 b
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 $$ ... $$;
> 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-procedura
Andrew Dunstan 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 someone forgo
2009/8/15 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 some
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 keywor
2009/8/15 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 ne
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 would
* 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
> 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
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:
http://www
Tom Lane wrote:
> Andrew Dunstan 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 like:
postgr
2009/8/10 Robert Haas :
> On Mon, Aug 10, 2009 at 11:36 AM, Tom Lane wrote:
>> Andrew Dunstan 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 wr
On Mon, Aug 10, 2009 at 11:36 AM, Tom Lane wrote:
> Andrew Dunstan 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 eve
Andrew Dunstan 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 you would then
>
Kevin Grittner wrote:
Peter Eisentraut 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 several ways.
One fa
Peter Eisentraut 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 changes to your su
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 ar
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 pa
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
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 " are.
The * was reaction to Toms fears of standard adding GRANT ON ALL with
conflicting meaning, but I don't reall
> 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
> featu
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 confus
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 t
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
>
> \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;
On Aug 5, 2009, at 11:59 AM, Tom Lane wrote:
Robert Haas 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.
* 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 i
On Aug 5, 2009, at 4:55 PM, Tom Lane wrote:
Josh Berkus 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 confu
Josh Berkus 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,
> *Buil
> 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
2009/8/5 Tom Lane :
> Robert Haas 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
On Wed, Aug 5, 2009 at 3:40 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 inability to add/remove co
On Wed, Aug 5, 2009 at 2:57 PM, Josh Berkus 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 connect to Pos
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
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
Petr Jelinek 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 have a feeling that th
Robert Haas 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 can always write a
On Wed, Aug 5, 2009 at 12:40 PM, Tom Lane wrote:
> Robert Haas 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 Comm
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, so
Robert Haas 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 that patch too, ev
On Mon, Jul 20, 2009 at 2:12 AM, Nikhil
Sontakke 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 understanding is that this patch w
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
wi
On Fri, Jul 17, 2009 at 9:16 AM, Petr Jelinek 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
--
Sent via
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
GRANT
Nikhil Sontakke wrote:
grant.sgml
* Maybe we should use
schemaname in the sgml
references instead of just schemaname
+There is also the posibility of granting permissions to all objects of
+given type inside one or multiple schemas. This functionality is supported
+for tables, views
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
schemaname in the sgml
references instead of just schemaname
+There is also the posibility of granting permissions t
On Tue, 2009-07-07 at 11:16 -0400, Tom Lane wrote:
> Simon Riggs 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
On Tue, Jul 7, 2009 at 4:16 PM, Tom Lane 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 kluge, and
Simon Riggs 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 rather than just f
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
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
*** a/doc/src/sg
--On Mittwoch, Juni 17, 2009 16:44:53 +0300 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 m
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 alway
On Wed, Jun 17, 2009 at 12:25 PM, Guillaume
Smet wrote:
> 2009/6/17 Petr Jelinek :
>> I agree that Default ACLs are more important and I already offered Stephen
>> help on that. But I've seen countless requests for granting on all tables to
>> a user and I already got some positive feedback outside
Greg Stark wrote:
Isn't the answer to grant permissions to a role and then just put
people in that role?
Still have to give permissions at least to that role.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
Isn't the answer to grant permissions to a role and then just put
people in that role?
--
Greg
On 17 Jun 2009, at 17:25, Guillaume Smet
wrote:
2009/6/17 Petr Jelinek :
I agree that Default ACLs are more important and I already offered
Stephen
help on that. But I've seen countless requ
2009/6/17 Petr Jelinek :
> I agree that Default ACLs are more important and I already offered Stephen
> help on that. But I've seen countless requests for granting on all tables to
> a user and I already got some positive feedback outside of the list, so I
> believe there is demand for this. Also t
Tom Lane erote:
Peter Eisentraut 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
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 possi
* 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
Peter Eisentraut 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 important in pract
On Wednesday 17 June 2009 17:15:04 Tom Lane wrote:
> Peter Eisentraut 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
>
* 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
>> defau
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 u
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 confusion
1 - 100 of 106 matches
Mail list logo
