Yes that is the case. (if you'd like quotes, shoot email)
However, the standard does not define anything at all to avoid clashing identifiers. The possibility of that problem is not even mentioned. Although it moves slowly, it does move. Anybody that decides to extend the I_S should plan for the possibility of conflicts I don't really care how name clashes are avoided but it is my opinion that if you decide to extend, you need to plan in advance on what you will do to avoid clasing identifiers. Now, the standard explictly allows extensions in two ways: implementations can define new I_S tables, but also new I_S columns. I think extensions in both directions make sense, and it'd be grand if in both cases the same approach was taken to avoid future name clashes. A separate schema would solve all problems. You'd have one schema for the actual physical definition, and one for the public interface (the I_S). If the views feature would come back, there'd plenty of opportunity to implement a standards compliant I_S without ever having to suffer conflicts in that regard. (hope I'm making sense, I had a few too much to celebrate a personal victory) tada, Roland. On Sat, Apr 18, 2009 at 2:14 AM, Baron Schwartz <[email protected]> wrote: > On Fri, Apr 17, 2009 at 4:12 PM, Stewart Smith <[email protected]> > wrote: >> On Fri, Apr 17, 2009 at 10:33:25AM -0400, Jay Pipes wrote: >>> Baron Schwartz wrote: >>> > On Mon, Apr 13, 2009 at 9:12 PM, Stewart Smith <[email protected]> >>> > wrote: >>> >> But this is more performance schema than information schema. >>> > >>> > Is it a good idea to follow MySQL's lead in separating those two? >>> >>> Depends. If MySQL separated them b/c of the current I_S implementation's >>> performance problems, then no. If for some other reason, perhaps... >> >> There is a standard for I_S, so we should follow that where we can. >> >> In my mind, the sep is I_S is standardised while a PERF_SCHEMA or >> whatever is whatever we can grab from internals that may be useful to >> people. i.e. not standard at all, not data dictionary based - but rather >> tied to internals. > > I am probably ignorant, but as I understand it, the I_S standard > specifies the common denominator and says any extensions to that are > fine. Is that not the case? > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp > -- Roland Bouman http://rpbouman.blogspot.com/ _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
