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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
