Dominique Devienne:
Can't event-triggers also be available to DB owners, instead of just SUPERUSER?
There's a recent -hackers thread exactly about this:
https://www.postgresql.org/message-id/flat/CAGRrpzbtYDkg7_xwfzrqByYgCJQbbL38tADyuN%2B6tAkbA-Pnkg%40mail.gmail.com
Best,
Wolfgang
Tom Lane:
If you err in the other direction, you don't get slapped on the
wrist that way. We're willing to inline VOLATILE functions,
for instance, whether or not the contained expression is volatile.
Similarly for STRICT, and I think parallel safety as well.
So my own habit when writing a SQL f
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 -
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
Dominique Devienne:
Hi David. I did as you suggested, and it fails the same way. Did I
misunderstand you? --DD
[..]
ddevienne=> grant dd_owner to dd_admin with admin option; --
I think this needs to be the other way around:
grant dd_admin to dd_owner with admin option;
Best,
Wol
Dominique Devienne:
1) Is there any way to know the current_role of the caller of a
DEFINER function. I fear the answer is no, but better be sure from
experts here.
You can do something like this:
CREATE DOMAIN current_user_only AS text
CONSTRAINT current_user_only CHECK (VALUE = CURRENT_USE
Erik Wienhold:
A single DEFINER function works if you capture current_user with a parameter
and default value. Let's call it claimed_role. Use pg_has_role[0] to check
that session_user has the privilege for claimed_role (in case the function is
called with an explicit value), otherwise raise an
Dominique Devienne:
I wish for DB-specific ROLEs BTW...
Same here. That would be so useful.
Abdul Qoyyuum:
Wouldnt you need to connect to the database first before you can ALTER
ROLE anything?
Of course, otherwise the notion of "current database" wouldn't make
sense at all. But that's only before executing the code. I am not
writing and executing this code at the same time.
In my
Hi,
I'm trying to set a GUC for a role in the current database only - but
don't know the name of the database at the time of writing code. Could
be development, staging, ...
I would basically like to do something like this:
ALTER ROLE a IN CURRENT DATABASE SET b TO c;
Although that syntax d
Tom Lane:
I think you're on fairly shaky ground here. Generally speaking, a CTE
will be executed/read only when the parent query needs the next row from
it. Your examples ensure that the CTE is read before the parent query's
results are computed; but in realistic usage you'd presumably be joini
Hi,
with PostgREST [1] we are translating HTTP requests into SQL queries.
For each request we are setting some metadata (headers, ...) as GUCs.
We used to do it like this:
SET LOCAL request.headers.x = 'y';
...
Since this is user-provided data, we want to use parametrized/prepared
statements
12 matches
Mail list logo
