public inbox for pgsql-performance@postgresql.org
help / color / mirror / Atom feedFrom: Pavel Stehule <pavel.stehule@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: proposal: schema variables
Date: Fri, 27 Oct 2017 07:08:43 +0200
Message-ID: <CAFj8pRAemkdaDuoRQzrhs2GU59Bb_yHuquJC6nyrwGHfVdLuLw@mail.gmail.com> (raw)
In-Reply-To: <20171026220732.GI4496@localhost>
References: <CAFj8pRDY+m9OOxfO10R7J0PAkCCauM-TweaTrdsrsLGMb1VbEQ@mail.gmail.com>
<20171026220732.GI4496@localhost>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Hi
2017-10-27 0:07 GMT+02:00 Nico Williams <nico@cryptonector.com>:
> 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.
>
My proposal doesn't expecting with nesting, because there is only one scope
- schema / session - but I don't think so it is necessary
current_user is a function - it is based on parser magic in Postgres. The
origin from Oracle uses the feature of ADA language. When function has no
parameters then parenthesis are optional. So current_user, current_time are
functions current_user(), current_time().
> 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?
>
these variables are pined to schema - so there is not any relation to
stack. It is like global variables.
Theoretically we can introduce "functional" variables, where the value is
based on immediate evaluation of expression. It can be very similar to
current current_user.
>
>
> I recently posted proposing a feature such that SECURITY DEFINER
> functions could observe the _caller_'s current_user.
>
your use case is good example - this proposed feature doesn't depend on
stack, depends on security context (security context stack) what is super
set of call stack
Regards
Pavel
> Nico
> --
>
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: pavel.stehule@gmail.com, nico@cryptonector.com, pgsql-hackers@postgresql.org
Subject: Re: proposal: schema variables
In-Reply-To: <CAFj8pRAemkdaDuoRQzrhs2GU59Bb_yHuquJC6nyrwGHfVdLuLw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox