The OBJECT_ID function in SQL Server is very useful for resolving an object name that is not fully qualified using the name resolution rules that apply for calling that function/procedure. So for instance, if I call the SP name foobar, T-SQL will first look within the current user schema, then within the dbo schema. If they both have a foobar SP, the one in the user schema will be called. The OBJECT_ID function resolves to an object id in the same way.
For Oracle though, things are more complicated as there is the concept of a package name as well. So for instance doe.foobar could refer to the package doe that has a procedure foobar OR it could refer to user schema doe with procedure foobar. There are rules for this that Oracle uses (which include synonyms as well), but I can't seem to find a function that will let me either resolve the name how Oracle's compiler would or get the object id that matches what Oracle's compiler would find.
So after all of that my question is: Is there some way of doing this without trying to recreate the name resolution rules that Oracle uses internally?
I probably didn't understand the question, but - here's what Oracle does. I was kind of lazy creating a new user whose name is
dboso I usedscottinstead, but I guess it doesn't matter much.Currently connected as
scottCreating a package named
scott(obviously, owned byscott, which means it is inscottschema) and a functionfoobarin it (which returns where I am):Creating a standalone function named
foobar(again, owned byscott):OK; so, what's being returned when we call them gradually (
foobar>scott.foobar>scott.scott.foobar):Therefore, there's no ambiguity; rules are rules. The only ambiguous thing (from my, human point of view) was produced by me. What the heck forced me to create a package named
scott?As of object ID: is this what you're looking for?
[EDIT]
After reading your comment, perhaps this answers your question (at least, a little bit):
So, that's a function which doesn't accept any parameters and returns a string.