Hi Roland! On Fri, Mar 19, 2010 at 08:45:52PM +0100, Roland Bouman wrote: > >> mm, one information_schema per catalog. I don't mind, but I guess this > >> means that once you commit to implementing catalogs, you have to go > >> all the way, and do this too...if you don't, generic clients will get > >> confused (use case: query or reporting tool that accesses drizzle via > >> a JDBC driver. Driver says the RDBMS supports catalogs, client uses > >> this information and then relies on an information_schema being > >> present....) > > > > We are already doing this at the schema/table level with the > > authorization plugins. For example, If I am user X and only have access > > to schemas A and B, my view of I_S will only contain those schemas > > and associated tables. We simply need to extend the namespace for > > authorization plugins to include catalog as well. Our API is currently: > > Ok. I wrote this, because I think that at the SQL level this means one > should be able to do: > > from <catalog-name>.information_schema.<table-name>
I'm not sure if this should be allowed or not (leaning towards no, does the standard say?). We may want to require always having a catalog context, and not allowing catalog in a fully-qualified table name. Of course in the protocol there is no way to specify a catalog on connect (at least MySQL protocol), so we would need some default catalog depending on user. They could then SET CATALOG x like you show below (and this may be the only required auth check for catalog). My initial comment about the auth API calls for schema/table level checks are probably be incorrect. They may not need a catalog argument since they will already have a catalog context from the SET. > I cant judge whether that is covered by the function calls you > included in your post, but this seems to be the consequence at the SQL > level. > I guess you'd also need to implement: > > <set catalog statement> ::= SET <catalog name characteristic> > <catalog name characteristic> ::= CATALOG <value specification> > > (this is going to be a bit awkward, as MySQL uses the USE syntax for > schemas/database. Standard defines SET for schemas too - USE is mysql > proprietary) Yeah. Since MySQL doesn't expose catalogs at all (other than 'def' for all column entries in the protocol response if you dump the raw packets), there will be more to grasp than just syntax. :) Hopefully the abstractions in the environments where catalogs are used will make using them intuitive (ie, I have access to account or domain X, which maps to a catalog of the same name). For those folks who have no interest in dealing with catalogs, they should never see them or need to deal with setting them (get the default NULL catalog). Best regards, -Eric _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
