Hi 2016-02-09 23:41 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com>:
> 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. > The schema variables are private by design. It can be enhanced in future, but now it is out my scope. If you need public access to these variables, you can use a functions. The access to functions can be controlled by a rights. We can introduce a private (schema limited) function too, but again it is out scope of this proposal. > 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. > I am happy, so you are opened the question about that package. Originally the Oracle package is a Ada language feature, but if you compare Oracle schemas and Postgresql schemas, you should to see a significant differences. Our schemas are much more similar to Oracle packages than Oracle schemas. So introduction of packages to Postgres is contra productive - will be pretty messy to have the packages and the schemas together. We don't need packages, because we have schemas, but we have not any safe (and simply used) schema scope tools. I implemented Orafce and the main problems there are not missing packages, but different default casting rules and missing procedures. > > 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). It is. Outer function level is a schema. I though about possible feature: DECLARE xxx int%SCHEMASCOPE; But it can be pretty difficult checked - other function can has "DECLARE xxx bigint%SCHEMASCOPE;" and what is valid version. Currently we can do validation of any function without checking any other functions. If I miss extern living object, then I have to do validation all functions in schema together. What is much more expensive. I don't would to introduce slower Oracle compilations and dependency issues. So I need externally created object. It was reason, why I used a statement CREATE instead statement DECLARE. Regards Pavel Regards Pavel
