* Robert Haas (robertmh...@gmail.com) wrote:
> Oh, I didn't realize that you were proposing a database-wide setting;
> my point was just that the way the feature looks to the user doesn't
> have to dictate the catalog representation.
I agree that the features don't have to define the catalog
repre
On Thu, Nov 10, 2011 at 11:17 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Nov 10, 2011 at 10:52 PM, Stephen Frost wrote:
>> > Certainly a big one that people get caught by is our default of execute
>> > to public on functions.. Most of our privileges are se
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 10, 2011 at 10:52 PM, Stephen Frost wrote:
> > Certainly a big one that people get caught by is our default of execute
> > to public on functions.. Most of our privileges are set up as minimal
> > access to others, functions are an oddity
On Thu, Nov 10, 2011 at 10:52 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost writes:
>> > A LOT of catalog bulk..? Am I missing something here?
>>
>> What I'm missing is what actual benefit we get from spending the extra
>> space. (No, I don't believe that ch
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > A LOT of catalog bulk..? Am I missing something here?
>
> What I'm missing is what actual benefit we get from spending the extra
> space. (No, I don't believe that changing the defaults is something
> that users commonly will or
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> To actually get rid of acldefault, we'd have to do that not only for
>> types but for all objects with ACLs. That's a LOT of catalog bulk,
>> and like Robert I'm not seeing much benefit. It's not unreasonable
>> to want the typica
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Thu, Nov 10, 2011 at 3:17 PM, Peter Eisentraut wrote:
> >> No, I'm pondering having pg_default_acl initialized so that newly
> >> created types have explicit USAGE privileges in their typacl column, so
> >> acldefault() wouldn't
Robert Haas writes:
> On Thu, Nov 10, 2011 at 3:17 PM, Peter Eisentraut wrote:
>> No, I'm pondering having pg_default_acl initialized so that newly
>> created types have explicit USAGE privileges in their typacl column, so
>> acldefault() wouldn't be needed. (And builtin types would have their
>
On Thu, Nov 10, 2011 at 3:17 PM, Peter Eisentraut wrote:
> On ons, 2011-11-09 at 00:21 -0500, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > Let me put this differently. Should we either continue to hardcode the
>> > default privileges in the acldefault() function, or should we instead
>> > in
On ons, 2011-11-09 at 00:21 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > Let me put this differently. Should we either continue to hardcode the
> > default privileges in the acldefault() function, or should we instead
> > initialize the system catalogs with an entry in pg_default_acl as
Peter Eisentraut writes:
> Let me put this differently. Should we either continue to hardcode the
> default privileges in the acldefault() function, or should we instead
> initialize the system catalogs with an entry in pg_default_acl as though
> ALTER DEFAULT PRIVILEGES GRANT USAGE ON TYPES TO P
On mån, 2011-11-07 at 12:21 -0500, Robert Haas wrote:
> > As I'm plotting to write code for this, I wonder about how to handle
> > default privileges. For compatibility and convenience, we would
> still
> > want to have types with public privileges by default. Should we
> > continue to hardcode t
On Sat, Nov 5, 2011 at 10:35 AM, Peter Eisentraut wrote:
> During the closing days of the 9.1 release, we had discussed that we
> should add privileges on types (and domains), so that owners can prevent
> others from using their types because that would prevent the owners from
> changing them in c
During the closing days of the 9.1 release, we had discussed that we
should add privileges on types (and domains), so that owners can prevent
others from using their types because that would prevent the owners from
changing them in certain ways. (Collations have similar issues and work
quite simil
14 matches
Mail list logo
