2016-12-30 11:03 GMT+01:00 Craig Ringer <cr...@2ndquadrant.com>: > On 30 December 2016 at 17:29, Craig Ringer <cr...@2ndquadrant.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 >
