Hi Roland, On Fri, Mar 19, 2010 at 09:58:07PM +0100, Roland Bouman wrote: > On Fri, Mar 19, 2010 at 9:23 PM, Eric Day <[email protected]> wrote: > > 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 > > Standard says: > > <schema name> ::= [ <catalog name> <period> ] <unqualified schema name>
Ahh, thanks. I doubt many folks would use this syntax (or even know it exists), but we should probably should support it if it's not too much trouble. > On authentication and default catalog, the standard says: > > " > 4.37.2 SQL-session identification > ... > An SQL-session has a default catalog name that is used to effectively > qualify unqualified <schema name>sthat are contained in <preparable > statement>s when those statements are prepared in the current > SQL-session by either an <execute immediate statement> or a <prepare > statement> or are contained in <direct SQL statement>s when those > statements are invoked directly. The default catalog name is initially > set to an implementation-defined value but can subsequently be changed > by the successful execution of a <set catalog statement> or <setschema > statement>. > " Cool, this means that since the default is implementation-defined, we can have auth plugins set this depending on the identifier they login as. For example, if the login as [email protected], they would get the catalog that maps to 'drizzle.org'. By default they should get the NULL catalog name, and is what everyone gets if no auth is involved. > Yeah, that'd be great if you can solve it transparently. Perhaps I am > being under-appreciative of the merits of catalogs, but I don't see > the light yet. There may be a small number of organizations/DBAs who want these features, but there are potentially lots of users who would depend on them without knowing (shared hosting environments). 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
