On Sat, Oct 31, 2015 at 10:42 AM, David Fetter wrote:
> On Sat, Oct 31, 2015 at 12:16:31AM +0100, Robert Haas wrote:
>> On Thu, Oct 29, 2015 at 10:31 PM, David Fetter wrote:
>> > Had this been part of the original ALTER DEFAULT PRIVILEGES patch,
>> > those
On Sat, Oct 31, 2015 at 12:16:31AM +0100, Robert Haas wrote:
> On Thu, Oct 29, 2015 at 10:31 PM, David Fetter wrote:
> > Had this been part of the original ALTER DEFAULT PRIVILEGES patch,
> > those privileges would simply have been applied. Since it wasn't, I'm
> > ass-u-me'ing
On Thu, Oct 29, 2015 at 10:31 PM, David Fetter wrote:
> Had this been part of the original ALTER DEFAULT PRIVILEGES patch,
> those privileges would simply have been applied. Since it wasn't, I'm
> ass-u-me'ing that changing the default behavior to that is going to
> cause
Folks,
I've run into a problem recently, and I can't be the first to have
done so, and it's this.
We have a pretty sophisticated capability via ALTER DEFAULT
PRIVILEGES. When the creating role creates something in a schema so
altered, all kinds of nice recursive granting happens. That's well
David Fetter writes:
> Since it's not a green field project, I would like to propose the
> following addition to the ALTER ... OWNER TO ... construct:
> ALTER ... OWNER TO ... [{NEW | OLD} DEFAULT PRIVILEGES]
> What say?
I'd say "you haven't actually defined what either of
On Thu, Oct 29, 2015 at 02:25:14PM -0400, Tom Lane wrote:
> David Fetter writes:
> > Since it's not a green field project, I would like to propose the
> > following addition to the ALTER ... OWNER TO ... construct:
> > ALTER ... OWNER TO ... [{NEW | OLD} DEFAULT PRIVILEGES]
> >