On Saturday 31 January 2009 19:30:36 Andrew Dunstan wrote:
> >
> >
> > Allow GRANT/REVOKE permissions to be applied to all schema objects
> > with one command
> > The proposed syntax is: GRANT SELECT ON ALL TABLES IN public TO
On Sun, Feb 01, 2009 at 12:12:47AM +, Grzegorz Jaskiewicz wrote:
> On 1 Feb 2009, at 00:05, Joshua Tolley wrote:
>> to add new syntax, you might consider writing a function instead. This
>> function might take parameters such as the privilege to grant and the
>> user to
>> grant it to, and be
On Sun, Feb 01, 2009 at 10:25:29AM +, Gregory Stark wrote:
> > removing it from keywords.c and adding it to unserserved_keywords crowd
> > didn't
> > make it... so I'll stick with keywords.c for timebeing.
>
> I'm sorry if I was unclear. It needs to be in keywords.c but can probably be
> mar
Grzegorz Jaskiewicz writes:
> On 31 Jan 2009, at 17:17, Gregory Stark wrote:
>>
>> I don't see any reason offhand why it should have to be a reserved word
>> though. You should be able to make it an UNRESERVED_KEYWORD. Oh, and you'll
>> want to add it to the list of tokens in unreserved_keyword
On 1 Feb 2009, at 10:25, Gregory Stark wrote:
I'm sorry if I was unclear. It needs to be in keywords.c but can
probably be
marked as UNRESERVED_KEYWORD there rather than RESERVED_KEYWORD.
In other words there are two places where you have to indicate
whether it's
reserved or not, keyword
Grzegorz Jaskiewicz wrote:
On 31 Jan 2009, at 17:22, David Fetter wrote:
Is this part of the SQL:2008? If not, is there something else that
is?
As far as I can see in the 'free' draft, no. Which is quite funny, cos
'DATABASE' keyword isn't there too..
Anyway. Looks like m$'s sybase clone
On 31 Jan 2009, at 17:22, David Fetter wrote:
Is this part of the SQL:2008? If not, is there something else that
is?
As far as I can see in the 'free' draft, no. Which is quite funny, cos
'DATABASE' keyword isn't there too..
Anyway. Looks like m$'s sybase clone got it, so I figure - at lea
On 31 Jan 2009, at 17:17, Gregory Stark wrote:
I don't see any reason offhand why it should have to be a reserved
word
though. You should be able to make it an UNRESERVED_KEYWORD. Oh, and
you'll
want to add it to the list of tokens in unreserved_keyword in gram.y
as well.
removing it fr
On 1 Feb 2009, at 00:05, Joshua Tolley wrote:
to add new syntax, you might consider writing a function instead. This
function might take parameters such as the privilege to grant and
the user to
grant it to, and be called something like this:
SELECT my_grant_function('someuser', 'someprivi
On Sat, Jan 31, 2009 at 05:40:57PM +, Grzegorz Jaskiewicz wrote:
> On 31 Jan 2009, at 17:30, Andrew Dunstan wrote:
>> But the syntax you posted does not do this at all. Where does it
>> restrict the grant to a single schema, like the syntax above?
> I am just starting the attempt here, obviou
On 31 Jan 2009, at 17:28, David Fetter wrote:
On Sat, Jan 31, 2009 at 05:24:15PM +, Grzegorz Jaskiewicz wrote:
from http://wiki.postgresql.org/wiki/Todo:
I see the TODO item, but I don't see anything in the SQL standard,
which I think is something we should explore before making a
potent
On 31 Jan 2009, at 17:30, Andrew Dunstan wrote:
But the syntax you posted does not do this at all. Where does it
restrict the grant to a single schema, like the syntax above?
I am just starting the attempt here, obviously since I admit that my
parser skills are next to none - I didn't addres
Grzegorz Jaskiewicz wrote:
from http://wiki.postgresql.org/wiki/Todo:
[E]
Allow GRANT/REVOKE permissions to be applied to all schema objects
with one command
The proposed syntax is: GRANT SELECT ON ALL TABLES IN public
On Sat, Jan 31, 2009 at 05:24:15PM +, Grzegorz Jaskiewicz wrote:
> from http://wiki.postgresql.org/wiki/Todo:
I see the TODO item, but I don't see anything in the SQL standard,
which I think is something we should explore before making a
potentially incompatible change.
Cheers,
David.
--
Dav
from http://wiki.postgresql.org/wiki/Todo:
[E] <>Allow GRANT/REVOKE permissions to be applied to all schema objects
with one command
The proposed syntax is: GRANT SELECT ON ALL TABLES IN public TO
phpuser; GRANT SELECT ON NEW TABLES IN public TO phpuser;
--
Sent via pgsql-hackers mailin
On 31 Jan 2009, at 17:17, Gregory Stark wrote:
Grzegorz Jaskiewicz writes:
You're going to kick yourself, but:
{"table", TABLE, RESERVED_KEYWORD},
+ {"table", TABLES, RESERVED_KEYWORD},
^
I don't see any reason offhand why it should have to be a reserved
wo
On Sat, Jan 31, 2009 at 04:46:26PM +, Grzegorz Jaskiewicz wrote:
> Hey folks,
>
> I am trying to add "GRANT SELECT ON ALL TABLES" to postgres,
Is this part of the SQL:2008? If not, is there something else that
is?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AI
Grzegorz Jaskiewicz writes:
You're going to kick yourself, but:
> {"table", TABLE, RESERVED_KEYWORD},
> + {"table", TABLES, RESERVED_KEYWORD},
^
I don't see any reason offhand why it should have to be a reserved word
though. You should be able to make it an UNRESERVED
On 31 Jan 2009, at 16:46, Grzegorz Jaskiewicz wrote:
+ {"table", TABLES, RESERVED_KEYWORD},
Gaaah, a typo...
:(
(another useless post to -hackers, by myself).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
Hey folks,
I am trying to add "GRANT SELECT ON ALL TABLES" to postgres, as it has
been quite few times now - where I had to write a procedure for that.
I kind of looked around, and more or less know how to approach it. But
I am stuck on parser :), yes - parser.
Can someone walk me through a
20 matches
Mail list logo
