Re: proposal: schema PL session variables

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(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-12 21:41:45
Message-ID: 56BE5199.1030009@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/12/16 2:58 PM, Pavel Stehule wrote:
>
> So I think adding something like this needs to at least address
> *how* SQL level access would work, *when* it's eventually implemented.
>
>
> I understand - and I agree.
>
> small note: Private variables should not be executed from any SQL,
> because SQL has not directly related schema. It can be executed only
> from SQL embedded in some object with attached schema - PL functions,
> views, constraints, .. So for this use case, the important information
> is info about a container. We have to hold info about related schema in
> planner/executor context.

I think that's probably true, but this also shows why we need to
consider different PLs too. As it stands right now, the only way to
access a variable outside of plpgsql would be to call a plpgsql
function, and currently there's no way to make a plpgsql function
private. So for this to work, private variables probably need to be
exposed directly through the pl handler.

Again, I'm not saying this all has to be implemented up front, but there
needs to be a plan for how it would work.

I think it would be a good idea to start a wiki page on this topic to
start collecting stuff together.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-02-12 21:59:14 Re: Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.
Previous Message Alvaro Herrera 2016-02-12 21:25:02 innocuous: pgbench does FD_ISSET on invalid socket