John Singleton wrote: > > Elke, > > >Yes, DDL does not perform name resolution > > > > > All DDL statements? Some, like DROP TABLE seem to perform resolution at > least on the first level...
Of course all commands check for private tables/views/synonyms without specifying the owner/schema for this. But further search levels are NOT used for DDL. And the other mail concerning the bad practice to write applications relying on the name resolution on levels above 1 (meaning: the search in the user's owner-namespace and the sysdba-namespace) means: perhaps there will be a release where this name resolution above level 1 will not be available any more. And as I wrote: relying on this name resolution may cause trouble if someone using your database-user or the user's owner will create tables/views/synonyms with exactly the name of the sysdba's table/view/synonym you used and expected so far. It is no problem of performance, but a problem of perhaps using other data/tablestructure than usually/the application can handle. Elke SAP Labs Berlin > Cheers, > JLS > Zabach, Elke wrote: > > >John Singleton wrote: > > > > > >>Hello all, > >> > >>So I think I've pretty much got MaxDB's name resolution system down. But > >>I just wanted to post to the list to make sure :) > >> > >>So, from what I've been able to determine, it works like this: > >> > >>1) Say I have three users. DBA, DBA2, and DBA2USER. DBA creates DBA2 > >>then DBA2 creates the resource user DBA2USER. > >>The ownership looks like this: > >>DBA > >> DBA2 > >> DBA2USER > >> > >>1) As user DBA2USER I issue the query, "Select * from sometable" > >> > >> > >>(Please excuse the pseudo-code :) ) > >> > >>Level 1: > >>Searches for an object named "sometable" owned by DBA2USER. > >> > >>IF FOUND > >> RETURN SUCCESS > >>ELSE > >> CONTINUE TO LEVEL 2 > >> > >>Level 2: > >>Searches for an object named "sometable" owned by DBA2 (the owner of > >>DBA2USER) > >> > >>IF FOUND > >> IF DBA2USER HAS PRIVILEGES > >> RETURN SUCCESS > >> ELSE > >> RETURN FAIL > >>ELSE > >> CONTINUE TO LEVEL3 > >> > >>Level3: > >>Searches for an object "sometable" owned by DBA (the owner of DBA2) > >> > >>IF FOUND > >> IF DBA2USER HAS PRIVILEGES > >> RETURN SUCCESS > >> ELSE > >> RETURN FAIL > >>ELSE > >> CONTINUE TO LEVEL 4 > >> > >>Level 4: > >>Searches for a public synonym named "sometable" > >> > >>IF EXISTS A PUBLIC SYNONYM "SOMETABLE" > >> IF DBA2USER HAS PRIVILEGES > >> RETURN SUCCESS > >> ELSE > >> RETURN FAIL > >> ELSE > >> RETURN FAIL > >> > >> > >>Test Questions: > >>1) How does this look? This model has been working in all of my tests > >>so far. > >> > >> > > > >It looks nearly correct. > >But public synonym would not be level 4, but level 2, increasing the > levels of search in dba2 and dba. > > > > > > > >>2) Some statements do not perform resolution. For example, the CREATE > >>SYNONYM statement does not perform resolution. The Select statement, > >>however, does. > >> > >>Example: > >>Given the catalog: > >> DBA.SOMETABLE > >> DBA.DBA2 > >> DBA2.DBA2USER (where the user DBA2USER has all privileges on > >>DBA.SOMETABLE) > >> > >>If DBA2USER does: "select * from SOMETABLE" then the query succeeds. > >>However if DBA2USER does, "CREATE PUBLIC SYNONYM S_SOMETABLE FOR > >>SOMETABLE" then the query fails. > >> > >>Is there a list of statements that do not perform name resolution? > >> > >> > >> > > > >Yes, DDL does not perform name resolution > > > >Elke > >SAP Labs Berlin > > > > > > > >>Many many thanks, > >> > >>JLS > >> > >> > >> > >>-- > >>MaxDB Discussion Mailing List > >>For list archives: http://lists.mysql.com/maxdb > >>To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > >> > >> -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
