On Fri, Nov 22, 2024 at 6:57 AM wrote:
> Yeah, this is still on my list of things to research more about
> eventually - currently still unsolved.
>
> For my use-case the NO RESET would need to apply until the end of the
> transaction, not end of the session.
>
> I imagine something like an extens
Eric Hanson:
Did you find some way to prevent RESET ROLE? I once advocated for a NO
RESET option on SET ROLE [1] so that RESET ROLE would be impossible for
the rest of the session. Still think it would be helpful.
Yeah, this is still on my list of things to research more about
eventually -
On Wed, Nov 13, 2024 at 12:02 PM wrote:
> I don't have any benchmarks, but the following data point:
>
> We use PostgREST [1] which connects to the database with one
> "authenticator" role. For each request it handles, it does a SET ROLE to
> a role defined in the Authorization Header (JWT).
>
>
Hi That said, having a million users is a bit strange. Do you want to give
each visitor to your website a unique Postgres role, or something like
that? I think this is unusual, but it should work.
OK, thanks for the feedback, all. It may not be necessary to have
such a fine grained syst
Dominique Devienne:
Hi. Sure, that's a good point, and a best practice IMHO.
But I already do that, and the original question remain,
i.e. how does PostgreSQL with thousands or millions of roles?
In my use case, 1000 LOGIN users, and 10'000 schema related ROLEs,
is possible, with can translate to
On 2024-Nov-13, Kaare Rasmussen wrote:
> Sorry if my original post was unclear, but I don't expect that there
> will be much more than perhaps a hundred roles. Each may have from a
> few up to a million users in them, though.
In Postgres, a user is a role. So if you have a hundred roles and a
mi
Hi Dominique
Hi. Sure, that's a good point, and a best practice IMHO.
But I already do that, and the original question remain,
i.e. how does PostgreSQL with thousands or millions of roles?
Sorry if my original post was unclear, but I don't expect that there will be
much more than perhaps
On Wed, Nov 13, 2024, 4:42 PM Achilleas Mantzios - cloud <
a.mantz...@cloud.gatewaynet.com> wrote:
>
> Exactly! In the later versions, security gets more and more refined and
> strengthened. So ppl should think about moving away from "public" , and
> start implementing finer grained schemes of sec
On Wed, Nov 13, 2024, 5:00 PM Vijaykumar Jain <
vijaykumarjain.git...@gmail.com> wrote:
>
>
> On Wed, Nov 13, 2024, 4:42 PM Achilleas Mantzios - cloud <
> a.mantz...@cloud.gatewaynet.com> wrote:
>
>>
>> Exactly! In the later versions, security gets more and more refined and
>> strengthened. So ppl
On 11/13/24 12:29, Alvaro Herrera wrote:
On 2024-Nov-13, Vijaykumar Jain wrote:
I tried to grant select permissions to 5000 different roles on one table,
It failed with row size too big already at 2443.
But you can grant select to one "reader" role, and grant that one role
to however many ot
On 2024-Nov-13, Vijaykumar Jain wrote:
> I tried to grant select permissions to 5000 different roles on one table,
> It failed with row size too big already at 2443.
But you can grant select to one "reader" role, and grant that one role
to however many other roles you want. This way you can have
On Wed, Nov 13, 2024 at 11:29 AM Alvaro Herrera wrote:
> On 2024-Nov-13, Vijaykumar Jain wrote:
> > I tried to grant select permissions to 5000 different roles on one table,
> > It failed with row size too big already at 2443.
>
> But you can grant select to one "reader" role, and grant that one r
12 matches
Mail list logo
