Re: proposal: schema PL session variables

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).