On Thu, Mar 25, 2010 at 8:27 PM, Stewart Smith <[email protected]> wrote: > On Thu, 25 Mar 2010 12:06:51 -0700, Brian Aker <[email protected]> wrote: >> You cannot though do an alter table on the standard table if the >> temporary table is around (which I personally think is bad). > > Although I wonder if anybody has ever ran into this (beyond fiddling in > a training course)? > > It could be a desired effect that the ALTER is to the temporary > table... I can see people using that as a way around really bad code in > some "enterprise" system that they're not allowed to change. But then > again, that's enterprise: which is rather distinct from sane. > >> We internally have three basic forms of tables. Temporary, Standard, >> and "Internal". We use internal for results/alter/etc. Those come up >> in error messages from time to time, but since the names are gibberish >> it is pretty simple to know when they are at fault (though not perfect). >> >> We have internally "temporary" reserved as a schema for our own use >> (same with data_dictionary and information_schema). Temporary you >> can't see though. Since "internal" tables live there, I've been having >> error messages write out as "internal.#sql34324" as the sql path for >> error messages. Right now temporary and standard are the same... but I >> would like to change that. > > If we just reserve '#' at the start of identifiers, then > "#temporary.#sql1234" is highly unlikely to collide with any user... I > could see people creating a schema called "temporary", but not "#temporary". > >> SqlServer uses a # symbol to represent those tables. I think we should >> do the same for error messages. In fact, I think we should reserve the >> "#" character for our own internal use and not allow its usage as the >> first character. > > (for anyone who's wondering, go read > http://msdn.microsoft.com/en-us/library/ms175874.aspx ) > > Although I'm a bit unclear as to if they support CREATE TABLE '#foo'; as > creating a temporary table.
Yes, they do. And no, I don't think this issue is worth the emails it's printed on. We have bigger fish to fry than whether or not temporary tables have a hash mark in front of them when printing. -jay _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
