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? 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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
