Josh's last suggestion (ALL TABLES IN someschema) seems to me to be a
reasonable compromise between usefulness, syntactic weirdness, and
hiding implementation details.
Maybe it is not necessary to extend the syntax to distinguish between
the two cases. Maybe it's worth considering to have
Hi Merlin,
sorry - I replied to Tom PG hackers before I saw you last post.
I think it is best to code the basic functionallity within the two new
commands, and see
how this works out. We can add your idea and others on top of it later
on.
what about that?
cheers,
Matthias
Matthias wrote:
I think it is best to code the basic functionallity within the two new
commands, and see
how this works out. We can add your idea and others on top of it later
on.
I think you should do whatever you think is most
appropriate...discussion can of course continue after you have a
Merlin Moncure [EMAIL PROTECTED] writes:
Is this:
GRANT SELECT ON ALL TABLES IN public TO phpuser;
GRANT SELECT ON NEW TABLES IN public TO phpuser;
Really better than this?
GRANT { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER
| EXECUTE | CREATE | ALL [ PRIVILEGES ] }
GRANT SELECT ON ALL TABLES IN public TO phpuser;
GRANT SELECT ON NEW TABLES IN public TO phpuser;
Really better than this?
GRANT { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES |
TRIGGER
| EXECUTE | CREATE | ALL [ PRIVILEGES ] }ON SCHEMA schemaname [,
...]
The latter
Merlin Moncure [EMAIL PROTECTED] writes:
Is the price of looking up a schema a deal breaker here, or is it
possible to avoid it?
My guess is no as to both questions. I've never seen any profiles
suggesting that permissions-checking is a significant part of query
startup. In any case, if you
1. TABLE
2. DATABASE
3. FUNCTION
4. LANGUAGE
5. SCHEMA
6. TABLESPACE
You left out SEQUENCES.
And views, but he was just listing the acceptable targets to the 'grant'
command. Basically, views and sequences are treated as tables in this
respect.
Merlin
Merlin Moncure [EMAIL PROTECTED] writes:
You left out SEQUENCES.
And views, but he was just listing the acceptable targets to the 'grant'
command. Basically, views and sequences are treated as tables in this
respect.
Right. Also, LANGUAGEs do not live within schemas, so they drop out of
On Fri, Jan 28, 2005 at 09:17:46PM +0100, Matthias Schmidt wrote:
a) accept some sort of wildcard for the grant on table syntax:
GRANT ... ON TABLE schema.*
What about a list,
GRANT ... ON TABLE table1, table2, ... TO user1, user2, ...;
It would be good if it was a list of wildcards. Not
Alvaro Herrera wrote:
On Fri, Jan 28, 2005 at 09:17:46PM +0100, Matthias Schmidt wrote:
a) accept some sort of wildcard for the grant on table syntax:
GRANT ... ON TABLE schema.*
What about a list,
GRANT ... ON TABLE table1, table2, ... TO user1, user2, ...;
It would be good if
Alvaro Herrera [EMAIL PROTECTED] writes:
What about a list,
GRANT ... ON TABLE table1, table2, ... TO user1, user2, ...;
We already allow a list (and have since at least 7.0).
It would be good if it was a list of wildcards.
I'm a bit itchy about allowing wildcards --- it doesn't seem to fit
On Sat, Jan 29, 2005 at 12:01:09AM -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
What about a list,
GRANT ... ON TABLE table1, table2, ... TO user1, user2, ...;
We already allow a list (and have since at least 7.0).
It would be good if it was a list of wildcards.
TODO1: Allow GRANT/REVOKE permissions to be applied to all schema
objects with one command.
TODO2: Assign Permissions to schemas wich get automatically inherited
by objects created in the schema.
a) should we pursue both of them?
b) how can a syntax for TODO1 look like? Anchored at 'GRANT
Hi Tom + *,
as I learned from severall posts this TODO splits into two distinct
TODO's
TODO1: Allow GRANT/REVOKE permissions to be applied to all schema
objects with one command.
TODO2: Assign Permissions to schemas wich get automatically inherited
by objects created in the schema.
my
14 matches
Mail list logo
