| From: | Nico Williams <nico(at)cryptonector(dot)com> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: proposal: schema variables |
| Date: | 2017-10-26 22:07:33 |
| Message-ID: | 20171026220732.GI4496@localhost |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
On Thu, Oct 26, 2017 at 09:21:24AM +0200, Pavel Stehule wrote:
> Comments, notes?
I like it.
I would further like to move all of postgresql.conf into the database,
as much as possible, as well as pg_ident.conf and pg_hba.conf.
Variables like current_user have a sort of nesting context
functionality: calling a SECURITY DEFINER function "pushes" a new value
onto current_user, then when the function returns the new value of
current_user is "popped" and the previous value restored.
It might be nice to be able to generalize this.
Questions that then arise:
- can one see up the stack?
- are there permissions issues with seeing up the stack?
I recently posted proposing a feature such that SECURITY DEFINER
functions could observe the _caller_'s current_user.
Nico
--
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2017-10-26 22:40:08 | bgwriter_lru_maxpages range in postgresql.conf |
| Previous Message | Michael Paquier | 2017-10-26 20:56:33 | Re: proposal: custom autovacuum entries |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2017-10-27 05:08:43 | Re: proposal: schema variables |
| Previous Message | Justin Pryzby | 2017-10-26 19:45:15 | Re: performance drop after upgrade (9.6 > 10) |