Re: proposal: schema PL session variables

On 2/10/16 1:29 PM, Pavel Stehule wrote:
> I got off list mail with little bit different syntax proposal
>
> CREATE VARIABLE xxx DEFAULT [ PRIVATE ]
>
> I am thinking so more SQL natural is form:
>
> CREATE [ PRIVATE ] VARIABLE xxx ...
>
> There should not be only variables, there can be tables, views,
> functions, ...
>
> The "PRIVATE" in this context means - only accessible from current
> schema. The syntax is different, than I propose, but the idea is same.

+1

>     I'm not saying we have to implement packages the same way oracle
>     did. Or at all.
>
>     My point is that there are MAJOR features that packages offer that
>     we don't have at all, with or without schemas. One of those features
>     is the idea of private objects. You CAN NOT do the same thing with
>     permissions either, because public vs private doesn't care one iota
>     about what role is executing something. They only care about what's
>     in the call stack.
>
>
> I don't understand well, and probably I don't explain my ideas well. But
> this exactly what I would to implement. The security based on locality,
> not based on roles.

+1 as well

>              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.
>
>
>     While this patch doesn't need to implement SQL access to variables,
>     I think the design needs to address it.
>
>
> SQL access to variables needs a) change in SQL parser (with difficult
> discussion about syntax) or b) generic get/set functions. @b can be used
> in other PL in first iteration.
>
> I afraid to open pandora box and I would to hold the scope of this patch
> too small what is possible - to be possible implement it in one release
> cycle.

I agree about implementation. I disagree about design.

Right now it appears zero thought has gone into what SQL level access 
would eventually look like. Which means there's a high risk that 
something gets implemented now that we regret later.

So I think adding something like this needs to at least address *how* 
SQL level access would work, *when* it's eventually implemented.
-- 
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