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