On 7/2/20 3:14 PM, Daniel Gustafsson wrote:
>> On 30 Mar 2020, at 20:28, Tom Lane wrote:
>>
>> Tomas Vondra writes:
>>> I see this patch is marked as RFC since 12/30, but there seems to be
>>> quite a lot of discussion about the syntax, keywords and how exactly to
>>> identify the superuser. So I
> On 30 Mar 2020, at 20:28, Tom Lane wrote:
>
> Tomas Vondra writes:
>> I see this patch is marked as RFC since 12/30, but there seems to be
>> quite a lot of discussion about the syntax, keywords and how exactly to
>> identify the superuser. So I'll switch it back to needs review, which I
>> th
Tomas Vondra writes:
> I see this patch is marked as RFC since 12/30, but there seems to be
> quite a lot of discussion about the syntax, keywords and how exactly to
> identify the superuser. So I'll switch it back to needs review, which I
> think is a better representation of the current state.
Hi,
I see this patch is marked as RFC since 12/30, but there seems to be
quite a lot of discussion about the syntax, keywords and how exactly to
identify the superuser. So I'll switch it back to needs review, which I
think is a better representation of the current state.
regards
--
Tomas Vondra
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> But, again, we already *have* a way of solving this problem: use
> quotes. As Simon pointed out, your proposed solution isn't really a
> solution at all, because & can appear in role names. It probably
> won't, but there probably also won't
Robert Haas writes:
> On Thu, Jan 9, 2020 at 11:06 AM Tom Lane wrote:
>> The problem is that we keep deciding that okay, it probably won't hurt
>> anybody if this particular thing-that-ought-to-be-a-reserved-word isn't
>> really reserved.
> But, again, we already *have* a way of solving this pro
On Thu, Jan 9, 2020 at 11:06 AM Tom Lane wrote:
> The problem is that we keep deciding that okay, it probably won't hurt
> anybody if this particular thing-that-ought-to-be-a-reserved-word isn't
> really reserved. Your exercise in justifying that for "superuser" is
> not unlike every other previo
Robert Haas writes:
> On Thu, Jan 9, 2020 at 10:06 AM Tom Lane wrote:
>> What I'm basically objecting to is the pseudo-reservedness. If we
>> don't want to dodge that with special syntax, we should dodge it
>> by making sure the keywords are actually reserved names.
> ...
> But I think I'm comi
On Thu, Jan 9, 2020 at 10:06 AM Tom Lane wrote:
> What I'm basically objecting to is the pseudo-reservedness. If we
> don't want to dodge that with special syntax, we should dodge it
> by making sure the keywords are actually reserved names.
You know, as I was reading this email, I got to thinki
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> What I'm basically objecting to is the pseudo-reservedness. If we
> don't want to dodge that with special syntax, we should dodge it
> by making sure the keywords are actually reserved names. In other
> words, add a "pg_" prefix, as somebody el
Simon Riggs writes:
> On Wed, 8 Jan 2020 at 23:55, Vik Fearing
> wrote:
>> What is being proposed is what is in the Subject and the original
>> patch. The other patch is because Tom didn't like "the continuing creep
>> of pseudo-reserved database and user names" so I wrote a patch to mark
>> suc
On Wed, 8 Jan 2020 at 23:55, Vik Fearing
wrote:
> On 08/01/2020 23:13, Peter Eisentraut wrote:
> > On 2020-01-06 17:03, Tom Lane wrote:
> >> So it's not clear to me whether we have any meeting of the minds
> >> on wanting this patch.
> >
> > This fairly far-ranging syntax reorganization of pg_hba
On 08/01/2020 23:13, Peter Eisentraut wrote:
> On 2020-01-06 17:03, Tom Lane wrote:
>> So it's not clear to me whether we have any meeting of the minds
>> on wanting this patch.
>
> This fairly far-ranging syntax reorganization of pg_hba.conf doesn't
> appeal to me. pg_hba.conf is complicated enou
On 2020-01-06 17:03, Tom Lane wrote:
So it's not clear to me whether we have any meeting of the minds
on wanting this patch.
This fairly far-ranging syntax reorganization of pg_hba.conf doesn't
appeal to me. pg_hba.conf is complicated enough conceptually for users,
but AFAICT nobody ever com
Vik Fearing writes:
> On 06/01/2020 17:03, Tom Lane wrote:
>> So it's not clear to me whether we have any meeting of the minds
>> on wanting this patch. In the meantime, though, the cfbot
>> reports that the patch breaks the ssl tests. Why is that?
> I have no idea. I cannot reproduce the fail
On 06/01/2020 17:03, Tom Lane wrote:
> So it's not clear to me whether we have any meeting of the minds
> on wanting this patch. In the meantime, though, the cfbot
> reports that the patch breaks the ssl tests. Why is that?
I have no idea. I cannot reproduce the failure locally.
--
Vik Fear
So it's not clear to me whether we have any meeting of the minds
on wanting this patch. In the meantime, though, the cfbot
reports that the patch breaks the ssl tests. Why is that?
regards, tom lane
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > On Thu, Jan 2, 2020 at 15:50 Tom Lane wrote:
> >> To cover the proposed functionality, you'd still need some way to
> >> select not-superuser. So I don't think this fully answers the need
> >> even if we wanted to do
Stephen Frost writes:
> On Thu, Jan 2, 2020 at 15:50 Tom Lane wrote:
>> To cover the proposed functionality, you'd still need some way to
>> select not-superuser. So I don't think this fully answers the need
>> even if we wanted to do it.
> Sorry- why do we need that..? The first match for a p
Greetings,
On Thu, Jan 2, 2020 at 15:50 Tom Lane wrote:
> Andrew Gierth writes:
> > "Tom" == Tom Lane writes:
> > Tom> Meh. If the things aren't actually roles, I think this'd just add
> > Tom> confusion. Or were you proposing to implement them as roles? I'm
> > Tom> not sure if that would
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Meh. If the things aren't actually roles, I think this'd just add
> Tom> confusion. Or were you proposing to implement them as roles? I'm
> Tom> not sure if that would be practical in every case.
> In fact my original suggestion when th
## Stephen Frost (sfr...@snowman.net):
> We already have a reserved namespace when it comes to roles,
> specifically "pg_".. why invent something new like this '&' prefix when
> we could just declare that 'pg_superusers' is a role to which all
> superusers are members? Or something along those l
Greetings,
On Thu, Jan 2, 2020 at 15:04 Tom Lane wrote:
> Stephen Frost writes:
> > We already have a reserved namespace when it comes to roles,
> > specifically "pg_".. why invent something new like this '&' prefix when
> > we could just declare that 'pg_superusers' is a role to which all
> >
> "Tom" == Tom Lane writes:
> Stephen Frost writes:
>> We already have a reserved namespace when it comes to roles,
>> specifically "pg_".. why invent something new like this '&' prefix
>> when we could just declare that 'pg_superusers' is a role to which
>> all superusers are members?
On 02/01/2020 20:52, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> On 29/12/2019 23:10, Vik Fearing wrote:
>>> On 29/12/2019 17:31, Tom Lane wrote:
Robert Haas writes:
> On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing
> wrote:
>> I'm all
Stephen Frost writes:
> We already have a reserved namespace when it comes to roles,
> specifically "pg_".. why invent something new like this '&' prefix when
> we could just declare that 'pg_superusers' is a role to which all
> superusers are members? Or something along those lines?
Meh. If t
Greetings,
* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> On 29/12/2019 23:10, Vik Fearing wrote:
> > On 29/12/2019 17:31, Tom Lane wrote:
> >> Robert Haas writes:
> >>> On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing
> >>> wrote:
> I'm all for this (and even suggested it during the IRC
On Mon, Dec 30, 2019 at 11:56:17AM +0100, Vik Fearing wrote:
> On 29/12/2019 23:10, Vik Fearing wrote:
> > On 29/12/2019 17:31, Tom Lane wrote:
> >> Robert Haas writes:
> >>> On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing
> >>> wrote:
> I'm all for this (and even suggested it during the IRC co
On 29/12/2019 23:10, Vik Fearing wrote:
> On 29/12/2019 17:31, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing
>>> wrote:
I'm all for this (and even suggested it during the IRC conversation that
prompted this patch). It's rife with bikeshedding, t
On 29/12/2019 17:31, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing
>> wrote:
>>> I'm all for this (and even suggested it during the IRC conversation that
>>> prompted this patch). It's rife with bikeshedding, though. My original
>>> proposal was to use '&'
On Sun, Dec 29, 2019 at 11:31 AM Tom Lane wrote:
> I don't have any particular objection to '&' if people prefer that.
> But ':' seems like it would introduce confusion with the
> variable-substitution notation used in psql and some other places.
>
> It's not that hard to imagine that somebody mig
Robert Haas writes:
> On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing
> wrote:
>> I'm all for this (and even suggested it during the IRC conversation that
>> prompted this patch). It's rife with bikeshedding, though. My original
>> proposal was to use '&' and Andrew Gierth would have used ':'.
> I
On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing wrote:
> > these keywords are syntactically distinct from ordinary names. Given
> > the precedent that "+" and "@" prefixes change what an identifier means,
> > maybe we could use "*" or some other punctuation character as a keyword
> > prefix? We'd ha
On 28/12/2019 19:07, Tom Lane wrote:
> Vik Fearing writes:
>> It can sometimes be useful to match against a superuser in pg_hba.conf.
> Seems like a reasonable desire.
>
>> Adding another keyword can break backwards compatibility, of course. So
>> that is an issue that needs to be discussed, but
Vik Fearing writes:
> It can sometimes be useful to match against a superuser in pg_hba.conf.
Seems like a reasonable desire.
> Adding another keyword can break backwards compatibility, of course. So
> that is an issue that needs to be discussed, but I don't imagine too
> many people are using
It can sometimes be useful to match against a superuser in pg_hba.conf.
For example, one could imagine wanting to reject nonsuperuser from a
particular database.
This used to be possible by creating an empty role and matching against
that, but that functionality was removed (a long time ago) by c
36 matches
Mail list logo
