2016-02-09 20:55 GMT+01:00 David G. Johnston <david.g.johns...@gmail.com>:
> 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. > Very important part of my proposal is independence on search_path. With search_path you have not any control over variable type, variable existence - and there are possible lot of impacts on plan cache, behave. So I propose SCHEMA VARIABLES with schema scope - and then search_path has zero effect on the behave. It doesn't introduce new dependencies. Pavel > > 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. > > David J. > > >
