Date: 25 Feb 2009 13:50:14 -0700
Bobby Z. (vladimir.zakharychev_at_gmail.com) wrote:
: On Feb 22, 6:56=A0am, yf..._at_vtn1.victoria.tc.ca (Malcolm Dew-Jones)
: > I noted that the sql statement he is building would have access to any
: > variables that are in scope within the do_something procedure.....
: It wouldn't - the SQL engine will see *bind* variables the PL/SQL
: engine automatically creates and binds for PL/SQL variables in scope.
: Functions can not be "bound" dynamically, so they must be declared
: globally to be visible to the SQL engine.
: > The fact that the *function* is not in scope, even though in virtually an=
: > other language a construct such as that would be in scope, and indeed eve=
: > though pl/sql itself is able to recognize some items (local variables) =
: > as being in scope, and indeed even though pl/sql itself has at least one
: > work around for another kind of object (types) so as to make it _appear_
: > to be in scope even when it isn't - the fact that the function is not in
: > scope is a limitation of the implementation of the pl/sql language.
: This is not a PL/SQL implementation limitation, this is how SQL works.
: Compare this to SQL calls in any other language: can you call your
: local functions in, say, Java or C from an SQL statement that your
: program executes (rhetorical question)?
According to Oracle (** emphsis is mine)
"PL/SQL is an imperative 3GL that was designed specifically for the ** seamless ** processing of SQL commands.
From another of their many documents
"Advantages of PL/SQL ... ** Tight integration ** with Oracle "
"The PL/SQL and SQL languages are ** tightly ** integrated
So I don't see a reason to compare pl/sql with Java or C in this regards.
The "seamless" processing of an an SQL statement that is within the scope of a package would be for it to be able to "see" the parts of the package that are in scope for any other type of statement.
Having to do something any more than that to make it visible is pretty much the definition of a seam.
Anyway, it doesn't matter.
$0.10 Received on Wed Feb 25 2009 - 14:50:14 CST