On Apr 22, 2006, at 1:13 PM, Florian G. Pflug wrote:
Why don't you just use SET SESSION AUTHORIZATION somerole, and then
scan
the to-be-executel sql scripts for any occurence of reset session
authorization,
and ignore the script it matches.
Of course you'd need to be a bit carefull to
Agent M wrote:
Sorry, but you misunderstand- nowhere am I interested in the role's
password. My previous suggestion was to add a password to set session
authorization itself so that if the authorization were to be reset, it
would need to be done with that password; the password itself could be
Florian G. Pflug [EMAIL PROTECTED] writes:
Why don't you just use SET SESSION AUTHORIZATION somerole, and then scan
the to-be-executel sql scripts for any occurence of reset session
authorization,
and ignore the script it matches.
What would probably be better is a way to do SET SESSION
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Why don't you just use SET SESSION AUTHORIZATION somerole, and then scan
the to-be-executel sql scripts for any occurence of reset session
authorization,
and ignore the script it matches.
What would probably be better is a way to do
Sorry, but you misunderstand- nowhere am I interested in the role's
password. My previous suggestion was to add a password to set session
authorization itself so that if the authorization were to be reset, it
would need to be done with that password; the password itself could be
Hello,
I have written a crontab-like daemon which accepts jobs from users through
a table and executes SQL statements after certain events or intervals.
This daemon maintains a persistent connection to the database as a
superuser.
The problem is that I wish to run arbitrary SQL as an
A.M. [EMAIL PROTECTED] writes:
It seems I am stuck so please allow me to propose an extension:
SET SESSION AUTHORIZATION user [WITH PASSWORD 'password];
This idea is extremely unlikely to be accepted, as the password would be
at risk of exposure in places like the pg_stat_activity view.
I
On Thu, Apr 20, 2006 at 04:06:19PM -0400, A.M. wrote:
The problem is that I wish to run arbitrary SQL as an unprivileged user
Would wrapping the SQL in a stored procedure with security
definer help any ?
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9
On Thu, April 20, 2006 4:21 pm, Tom Lane wrote:
A.M. [EMAIL PROTECTED] writes:
It seems I am stuck so please allow me to propose an extension:
SET SESSION AUTHORIZATION user [WITH PASSWORD 'password];
This idea is extremely unlikely to be accepted, as the password would be
at risk of
A.M. [EMAIL PROTECTED] writes:
On Thu, April 20, 2006 4:21 pm, Tom Lane wrote:
I think the correct way to do what you want is via a SECURITY DEFINER
function.
Perhaps I can't wrap my head around it- I have the SQL as a string in a
table.
Well, the simplest thing would be
create
I really haven't provided enough details- my fault. What I want to
accomplish is a general-purpose timer facility for postgresql. Ideally,
arbitrary roles provide statements to run at certain intervals. The
benefit here is that the user connections can go away and only a single
timer
Agent M [EMAIL PROTECTED] writes:
I really haven't provided enough details- my fault. What I want to
accomplish is a general-purpose timer facility for postgresql.
I'm not really sure why you think it'd be a good idea for such a thing
to operate as an unprivileged user that gets around its
12 matches
Mail list logo
