On Tue, Dec 23, 2014 at 11:44 AM, Stephen Frost [via PostgreSQL] <
ml-node+s1045698n5831875...@n5.nabble.com> wrote:
>
> It would be great to figure out a way to get feedback like this earlier
> on in the development. This patch has been floating around for quite a
> while, with intentional break
Stephen Frost writes:
> It would be great to figure out a way to get feedback like this earlier
> on in the development. This patch has been floating around for quite a
> while, with intentional breaks for feedback taken prior to incremental
> improvements and documentation additions. Clearly th
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Bruce Momjian wrote:
>
> > I am with Tom on this --- there is more wasted space in the 'name'
> > column pg_authid.rolname than by shoving 40 boolean values into a
> > bitmap. Adding the complexity of a bitmap doesn't make sense here. I
> > al
On Tue, Dec 23, 2014 at 01:43:47PM -0500, Stephen Frost wrote:
> > Offtopic, what I would really _love_ to see improved is our display of
> > object permissions:
>
> That's a whole different discussion and really belongs on a new thread.
> I'm certainly curious what ideas you have regarding how to
* Bruce Momjian (br...@momjian.us) wrote:
> I am with Tom on this --- there is more wasted space in the 'name'
> column pg_authid.rolname than by shoving 40 boolean values into a
> bitmap.
I agree that we waste a lot of space in 'name' but I don't think there's
an easy solution to that problem.
Bruce Momjian wrote:
> I am with Tom on this --- there is more wasted space in the 'name'
> column pg_authid.rolname than by shoving 40 boolean values into a
> bitmap. Adding the complexity of a bitmap doesn't make sense here. I
> also apologize for the late feedback.
Okay, it seems we have a m
José Luis Tallón-2 wrote
> On 12/23/2014 06:06 PM, Bruce Momjian wrote:
>> On Tue, Dec 23, 2014 at 11:34:09AM -0500, Tom Lane wrote:
>>> Stephen Frost <
> sfrost@
> > writes:
If that's the only consideration for this, well, that's certainly quite
straight-forward to change in the other
On 12/23/2014 06:06 PM, Bruce Momjian wrote:
On Tue, Dec 23, 2014 at 11:34:09AM -0500, Tom Lane wrote:
Stephen Frost writes:
If that's the only consideration for this, well, that's certainly quite
straight-forward to change in the other direction too. The new function
suggested by Andres actu
On Tue, Dec 23, 2014 at 11:34:09AM -0500, Tom Lane wrote:
> Stephen Frost writes:
> > If that's the only consideration for this, well, that's certainly quite
> > straight-forward to change in the other direction too. The new function
> > suggested by Andres actually makes it really easy to get a
Stephen Frost writes:
> If that's the only consideration for this, well, that's certainly quite
> straight-forward to change in the other direction too. The new function
> suggested by Andres actually makes it really easy to get a textual list
> of all the role attributes which a role has from th
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I'd have gone with just adding more bool columns as needed.
>
> > I don't think I was the only one concerned that adding a bunch of new
> > columns would bloat the size of pg_authid and
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Dec 23, 2014 at 10:51 AM, Tom Lane wrote:
> > Meh. To the extent that users look at pg_roles rather than pg_authid,
> > it's going to look like another 15 boolean columns to them anyway ...
> > except that now, those columns are suddenly a lo
José Luis Tallón wrote:
> On 12/23/2014 04:46 PM, Andres Freund wrote:
> >I personally would prefer a 'custom' type to represent the
> >permissions. Internally that could very well be current bitmask, but the
> >external representation could be more complex (i.e. some textual
> >representation). T
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-12-23 10:40:15 -0500, Robert Haas wrote:
> > I would have preferred (and I believe argued for) keeping the existing
> > catalog representation for existing attributes and using a bitmask for
> > new ones, to avoid breaking client code. But
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I'd have gone with just adding more bool columns as needed.
> I don't think I was the only one concerned that adding a bunch of new
> columns would bloat the size of pg_authid and the C structure behind it,
> but I'm not rememberin
On Tue, Dec 23, 2014 at 10:51 AM, Tom Lane wrote:
> Meh. To the extent that users look at pg_roles rather than pg_authid,
> it's going to look like another 15 boolean columns to them anyway ...
> except that now, those columns are suddenly a lot more expensive to read.
Ugh. I think that's actua
On 12/23/2014 04:46 PM, Andres Freund wrote:
[snip]
I find Tom's concern about needing more
than 64 attributes to be ill-founded; I can't really see that
happening on any timescale that matters.
Hmm... most probably, not (or so I hope)... Unless we begin to add many
differerent "capabilities",
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Again, I suppose I should have objected earlier, but I really seriously
> >> doubt that this is a good idea.
>
> > Ugh. I thought we had a consensus that this was the accepted way
> > forward; that's my read
Robert Haas writes:
> I would have preferred (and I believe argued for) keeping the existing
> catalog representation for existing attributes and using a bitmask for
> new ones, to avoid breaking client code. But I am not sure if that's
> actually the best decision. I find Tom's concern about ne
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I have to apologize for not having paid more attention, but ... is this
>> *really* such a great idea? You've just broken any client-side code
>> that looks directly at pg_authid.
> Anything which looks at pg_authid for the releva
On 2014-12-23 10:40:15 -0500, Robert Haas wrote:
> On Tue, Dec 23, 2014 at 10:26 AM, Alvaro Herrera
> wrote:
> > Tom Lane wrote:
> >> Again, I suppose I should have objected earlier, but I really seriously
> >> doubt that this is a good idea.
> >
> > Ugh. I thought we had a consensus that this wa
On Tue, Dec 23, 2014 at 10:26 AM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Again, I suppose I should have objected earlier, but I really seriously
>> doubt that this is a good idea.
>
> Ugh. I thought we had a consensus that this was the accepted way
> forward; that's my reading of the old thre
Alvaro Herrera writes:
> Tom Lane wrote:
>> Again, I suppose I should have objected earlier, but I really seriously
>> doubt that this is a good idea.
> Ugh. I thought we had a consensus that this was the accepted way
> forward; that's my reading of the old thread,
> http://www.postgresql.org/me
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > Use a bitmask to represent role attributes
> > The previous representation using a boolean column for each attribute
> > would not scale as well as we want to add further attributes.
>
> > Extra auxilliary functions are added to
Tom Lane wrote:
> Again, I suppose I should have objected earlier, but I really seriously
> doubt that this is a good idea.
Ugh. I thought we had a consensus that this was the accepted way
forward; that's my reading of the old thread,
http://www.postgresql.org/message-id/flat/20141016133218.gw28
Alvaro Herrera writes:
> Use a bitmask to represent role attributes
> The previous representation using a boolean column for each attribute
> would not scale as well as we want to add further attributes.
> Extra auxilliary functions are added to go along with this change, to
> make up for the los
26 matches
Mail list logo
