Re: proposal: schema PL session variables

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <obartunov(at)gmail(dot)com>
Subject: Re: proposal: schema PL session variables
Date: 2016-02-09 19:55:32
Message-ID: CAKFQuwbh+YBuyP_cUfw2dnLVqDD5djkEjg4BcwNhZNEReXAzWw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 9, 2016 at 11:32 AM, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
wrote:

>
> Oh, and I suggest we call them SESSION variables rather than SCHEMA
> variables, to reinforce the idea of how long the values in the variables
> live. A session variable is in a sense a 1x1 temp table, whose definition
> persists across sessions but whose value does not.
>
> Of course, if they do persist across sessions, then yeah, SCHEMA makes
> more sense. But every package variable in Oracle PL/SQL was initialized
> when the package was first loaded into the session.
>
>
​The key distinction for SCHEMA was that all functions in the schema would
be able to see them (and only those in the schema).

I am a bit partial, with little deep thought, to the IMPORT mechanic.
Changing them to actual session variables would be doable and you could
allow for the IMPORT specification to use search_path or explicit means to
locate said variables regardless of which schema​

​they exist in.

However, part of the goal is to blend into the broader database community
and thus increase porting capabilities. I'm not sure how well this would
help fulfill that goal.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2016-02-09 20:01:25 Re: Multi-tenancy with RLS
Previous Message Robert Haas 2016-02-09 19:47:46 Re: Multi-tenancy with RLS