On Tue, Feb 9, 2016 at 2:55 PM, David G. Johnston < david.g.johns...@gmail.com> wrote:
> On Tue, Feb 9, 2016 at 11:32 AM, Corey Huinker <corey.huin...@gmail.com> > wrote: > >> >> Oh, and I suggest we call them SESSION variables rather than SCHEMA >> variables, to reinforce the idea of how long the values in the variables >> live. A session variable is in a sense a 1x1 temp table, whose definition >> persists across sessions but whose value does not. >> >> Of course, if they do persist across sessions, then yeah, SCHEMA makes >> more sense. But every package variable in Oracle PL/SQL was initialized >> when the package was first loaded into the session. >> >> > The key distinction for SCHEMA was that all functions in the schema would > be able to see them (and only those in the schema). > > I am a bit partial, with little deep thought, to the IMPORT mechanic. > Changing them to actual session variables would be doable and you could > allow for the IMPORT specification to use search_path or explicit means to > locate said variables regardless of which schema > > they exist in. > > However, part of the goal is to blend into the broader database community > and thus increase porting capabilities. I'm not sure how well this would > help fulfill that goal. > > 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. 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.
