Re: proposal: session server side variables

2016-12-30 11:03 GMT+01:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:

> On 30 December 2016 at 17:29, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>
> > So .... lets take a step back or eight and ask "why?"
>
> Oh, and speaking of, I see Pavel's approach as looking for a
> PostgreSQL-adapted way to do something like Oracle's PL/SQL package
> variables. Right Pavel?
>

It was main motivation - the question was - how to share (in one session)
secure some information between function calls.

The PostgreSQL is specific in multi language support - but purpose is same.

>
> If so, their properties are, as far as I as a non-Oracle-person can tell:
>
> * Can be package-private or public. If public, can be both got and set
> by anyone. If private, can be got and set directly only by code in
> package. (Our equivalent is "by the owner"). As far as I can tell
> outside access to package-private variables still uses the variable
> get/set syntax, but is automatically proxied via getter/setter methods
> defined in the package, if defined, otherwise inaccessible.
>
> * Value not visible across sessions. Ever.
>
> * Can have an initialiser / DEFAULT value.
>
> * Non-persistent, value lost at session end.
>
> A typical example, where package variables are init'd from a table:
>
> http://www.dba-oracle.com/plsql/t_plsql_global_data.htm
>
> which relies on package initializers, something we don't have (but can
> work around easily enough with a little verbosity).
>
> This shows both public vars and package-private ones.
>
> See also https://docs.oracle.com/cd/B19306_01/appdev.102/b14261/
> constantvar_declaration.htm
>
>
> I believe these package variable properties are the properties Pavel
> seeks to model/emulate. Declared statically, value persistent only
> within the same session, non-transactional, can be private.
>
> Certainly there's nothing here that requires us to allow GRANTs.
> Simple ownership tests would supply us with similar functionality to
> what Oracle users have, allowing for our lack of packages and
> inability to hide the _existence_ of an object, only its contents.
>

The packages has own scope - so any access from packages is allowed. I
cannot do it in Postgres without explicitly written setter/getter
functions. So GRANTS reduces a requirement to write security definer
envelop functions.

Sure - owner doesn't need it. If your application is one user, or if you
are owner, then you don't need to use GRANT.

>
>
> My views:
>
> I am personally overwhelmingly opposed to variables that automagically
> create themselves when dereferenced, a-la Perl. Write $serialised
> (english spelling) not $serialized (US spelling) and you get a silent
> null. Fun! Hell. No. This is why failure to "use strict" in Perl is a
> near-criminal offense.
>
> I'd also strongly prefer to require vars to be declared before first
> use. Again, like "use strict", and consistent with how Pg behaves
> elsewhere. Otherwise we need some kind of magic syntax to say "this is
> a variable", plus vars that get created on first assignment suck
> almost as badly as ones that're null on undefined deference. Spend
> half an hour debugging and figure out that you typo'd an assignment.
> Again, "use strict".
>
> I fail to see any real utility to cross-session vars, persistent or
> otherwise, at this point. Use a normal or unlogged relation.
>
> I don't see the point of untyped variables with no ownership or rights
> controls. (ab)use a GUC. Note that you can achieve both xact-scoped
> and session-scoped that way, with xact-scoped vars assigned using SET
> LOCAL being unwound on xact end.
>
> Unless we also propose to add ON CONNECT triggers, I think some kind
> of persistency of declaration is useful but not critical. We'll land
> up with apps sending preambles of declarations on session start
> otherwise. But the most compelling use cases are for things where
> there'll be a procedure invoked by the user or app on connect anyway,
> so it can declare stuff there. I'm utterly unconvinced that it's
> necessary to have them in the catalogs to achieve static checking.
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>