Re: proposal: schema PL session variables

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(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 22:41:58
Message-ID: 56BA6B36.6020105@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/9/16 4:13 PM, Corey Huinker wrote:
>
> We're not going to get source compatibility without implementing
> packages, and there's no enthusiasm for that. It's been stated a few
> times before by some that the only value they see in packages is the
> package/session variables. Pavel's idea gives us that.

The other big thing you get is public vs private. You can
sorta-kinda-almost simulate that with permissions in simple cases, but
it ultimately falls apart as soon as you want a private function that
does something as the user calling the function.

When it comes to variables, I think it's a mistake to discuss this patch
while pretending that packages don't exist. For example all we wanted
were session variables, there's no reason they need to be tied to
schemas. The only reason to tie them to schemas is to try and fake
package support via schemas. I think it'd be a mistake to have
non-schema variables, but lets not fool ourselves as to why that would
be a mistake.

Another problem I have with this is it completely ignores public/private
session variables. The current claim is that's not a big deal because
you can only access the variables from a PL, but I give it 2 days of
this being released before people are asking for a way to access the
variables directly from SQL. Now you have a problem because if you want
private variables (which I think is pretty important) you're only choice
is to use SECDEF functions, which is awkward at best.

> I forgot to mention that if we're FROM-phobic the syntax could also be
>
> IMPORT my_schema.bar AS g_localtext IN OUT text
>
> Either way, you get the idea: the function defines what external globals
> it's willing to see, and gives an alias for them, and it's the same
> regardless of what the function language is.

ISTM that for plpgsql it would be better to add a namespace level above
the current top level (which is the function level).
--
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-09 22:53:59 Re: Tracing down buildfarm "postmaster does not shut down" failures
Previous Message Jim Nasby 2016-02-09 22:31:39 Re: proposal: schema PL session variables