Robert Haas writes:
> On Wed, Jun 29, 2011 at 8:53 PM, David Fetter wrote:
>> How about this?
>>
>> PostgreSQL grants some types of objects some default privileges to
>> PUBLIC. Tables, columns, schemas and tablespaces grant no privileges
>> to PUBLIC by default. For other types, the default p
On 06/29/2011 09:20 PM, Robert Haas wrote:
On Wed, Jun 29, 2011 at 8:53 PM, David Fetter wrote:
How about this?
PostgreSQL grants some types of objects some default privileges to
PUBLIC. Tables, columns, schemas and tablespaces grant no privileges
to PUBLIC by default. For other types, the
On Wed, Jun 29, 2011 at 8:53 PM, David Fetter wrote:
> How about this?
>
> PostgreSQL grants some types of objects some default privileges to
> PUBLIC. Tables, columns, schemas and tablespaces grant no privileges
> to PUBLIC by default. For other types, the default privileges granted
> to PUBLIC
On Wed, Jun 29, 2011 at 08:42:58PM -0400, Robert Haas wrote:
> On Wed, Jun 29, 2011 at 4:49 PM, Alvaro Herrera
> wrote:
> > Excerpts from Robert Haas's message of mié jun 29 13:42:34 -0400 2011:
> >
> >> > How about this?
> >> >
> >> > Some types of objects deny all privileges to PUBLIC by default
On Wed, Jun 29, 2011 at 4:49 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié jun 29 13:42:34 -0400 2011:
>
>> > How about this?
>> >
>> > Some types of objects deny all privileges to PUBLIC by default. These
>> > are tables, columns, schemas and tablespaces. For other type
On 06/29/2011 05:16 PM, David Fetter wrote:
Hmm, I like David's suggestion better, but I agree with you that
"deny" isn't the right verb there. I have no better suggestions at
moment though.
I chose "deny" in the sense of "default deny," which is a term of art
in security engineering referri
On Wed, Jun 29, 2011 at 04:49:15PM -0400, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of mié jun 29 13:42:34 -0400 2011:
>
> > > How about this?
> > >
> > > Some types of objects deny all privileges to PUBLIC by default.
> > > These are tables, columns, schemas and tablespaces. F
Excerpts from Robert Haas's message of mié jun 29 13:42:34 -0400 2011:
> > How about this?
> >
> > Some types of objects deny all privileges to PUBLIC by default. These
> > are tables, columns, schemas and tablespaces. For other types, the
> > default privileges granted to PUBLIC are as follows:
On Wed, Jun 29, 2011 at 1:20 PM, David Fetter wrote:
> On Wed, Jun 29, 2011 at 11:50:38AM -0400, Alvaro Herrera wrote:
>> Excerpts from Andrew Dunstan's message of mié jun 29 11:21:12 -0400 2011:
>> >
>> > I was just reading the docs on default privileges, and they say this:
>> >
>> > Dependin
On Wed, Jun 29, 2011 at 11:50:38AM -0400, Alvaro Herrera wrote:
> Excerpts from Andrew Dunstan's message of mié jun 29 11:21:12 -0400 2011:
> >
> > I was just reading the docs on default privileges, and they say this:
> >
> > Depending on the type of object, the initial default privileges
> >
Excerpts from Andrew Dunstan's message of mié jun 29 11:21:12 -0400 2011:
>
> I was just reading the docs on default privileges, and they say this:
>
> Depending on the type of object, the initial default privileges
> might include granting some privileges to PUBLIC. The default is no
>
I was just reading the docs on default privileges, and they say this:
Depending on the type of object, the initial default privileges
might include granting some privileges to PUBLIC. The default is no
public access for tables, columns, schemas, and tablespaces; CONNECT
privilege and
On Sun, Apr 4, 2010 at 9:59 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> On Sat, Apr 3, 2010 at 5:27 PM, Tom Lane wrote:
>>> Not sure if this is good enough or we need to provide some more-obvious
>>> way of dealing with it.
>
>> it's strange that a REVOKE doesn't clean what a GRANT did, and
Jaime Casanova writes:
> On Sat, Apr 3, 2010 at 5:27 PM, Tom Lane wrote:
>> Not sure if this is good enough or we need to provide some more-obvious
>> way of dealing with it.
> it's strange that a REVOKE doesn't clean what a GRANT did, and DROP
> OWNED BY seems very dangerous (at least if i forg
On Sat, Apr 3, 2010 at 5:27 PM, Tom Lane wrote:
> I wrote:
>> Yeah. The problem here is that once you've created an entry in
>> pg_default_acl, there is no way to make it go away.
>
> Actually that's not true: you can get rid of it with DROP OWNED BY.
> This fact is even documented in the ALTER D
I wrote:
> Yeah. The problem here is that once you've created an entry in
> pg_default_acl, there is no way to make it go away.
Actually that's not true: you can get rid of it with DROP OWNED BY.
This fact is even documented in the ALTER DEFAULT PRIVILEGES manual
page:
If you wish to dro
Jaime Casanova writes:
> I create some default privileges, now i'm trying to drop those roles
> but i get this error:
> mic=# drop role jcm;
> ERROR: role "jcm" cannot be dropped because some objects depend on it
> DETAIL: owner of default privileges on new relations belonging to
> role jcm in
Hi,
I create some default privileges, now i'm trying to drop those roles
but i get this error:
"""
mic=# drop role jcm;
ERROR: role "jcm" cannot be dropped because some objects depend on it
DETAIL: owner of default privileges on new relations belonging to
role jcm in schema public
"""
So i look
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> How do you feel about allowing functions to default to EXECUTE PUBLIC?
> Less excited, but if it gets us to the point of no known problems during
> upgrade we might as well do it.
Okay, I've changed the defaults for both language
Tom Lane writes:
> How do you feel about allowing functions to default to EXECUTE PUBLIC?
Less excited, but if it gets us to the point of no known problems during
upgrade we might as well do it.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)
Hello!
On Mon, 23 Sep 2002, Tom Lane wrote:
> I am thinking that the better course might be to have newly created
> languages default to USAGE PUBLIC, at least for a release or two.
>
> We might also consider letting newly created functions default to
> EXECUTE PUBLIC. I think this is less esse
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I am thinking that the better course might be to have newly created
>> languages default to USAGE PUBLIC, at least for a release or two.
> That seems reasonable. Since everyone is supposed to use createlang,
> that's the effectiv
Tom Lane writes:
> I am thinking that the better course might be to have newly created
> languages default to USAGE PUBLIC, at least for a release or two.
That seems reasonable. Since everyone is supposed to use createlang,
that's the effective default anyway.
--
Peter Eisentraut [EMAIL PRO
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > 7 . 3 O P E NI T E M S
> >
> > Loading 7.2 pg_dumps
> > functions no longer public executable
> > languages no longer public usable
>
>
> Although it's reasonably easy to fix no-privileges prob
Bruce Momjian <[EMAIL PROTECTED]> writes:
> 7 . 3 O P E NI T E M S
>
> Loading 7.2 pg_dumps
> functions no longer public executable
> languages no longer public usable
Although it's reasonably easy to fix no-privileges problems for
functions after you l
25 matches
Mail list logo
