On 2/10/16 1:29 PM, Pavel Stehule wrote:
I got off list mail with little bit different syntax proposal


I am thinking so more SQL natural is form:


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.


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

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to