Fix for bug#16716 for --ps-protocol mode.
item_cmpfunc.cc:
Fix for a memory allocation/freeing problem in agg_cmp_type() after fix
for bug#16377. Few language corrections.
The intermediate (not temporary) files of the new table
during ALTER TABLE was visible for SHOW TABLES. These
intermediate files are copies of the original table with
the changes done by ALTER TABLE. After all the data is
copied over from the original table, these files are renamed
to the original tables file names. So they are not temporary
files. They persist after ALTER TABLE, but just with another
name.
Normal GRANT checking takes place for the intermediate table.
Everyone who can see the original table (and hence the final
table) can also see the intermediate table. But noone else.
In 5.0 the intermediate files are invisible for SHOW TABLES
because all file names beginning with "#sql" were suppressed.
In 5.1 temporary files are created in TMPDIR, so that they
don't appear in the database directories. Also in 5.1 a
translation between table names and file names is done. The
tmp_file_prefix on file level is now "@0023sql".
The suppression of files starting with tmp_file_prefix is
still in place, but still only files beginning with "#sql"
were suppressed.
I do now translate tmp_file_prefix from table name to file
name before comparing it with the files in a directory.
This suppresses the intermediate files again.
No test case. The test case looks so that a reasonable big
table is altered while a second thread runs SHOW TABLES.
This in itself would be possible to do, but on slow machines
it would add too much time to the test suite, while on fast
machines the ALTER TABLE might have finished before SHOW
TABLES looks at the directory. Even if there might be a good
balance for todays machines, one day the test would become
void as the intermediate table would not be seen even with
the bug in place. I added a test script to the bug report.
It can easily be changed so that it uses a table size that
is appropriate for the test machine.
resulted in a wrong error message.
The nest_level counter indicates the depth of nesting for a subselect. It is
needed to properly resolve aggregate functions in nested subselects. Obviously
it shouldn't be incremented for UNION parts because they have the same level of
nesting. This counter was incremented by 1 in the mysql_new_select() function
for any new select and wasn't decremented for UNION parts. This resulted in
wrongly reported error messages.
Now the nest_level counter is decremented by 1 for any union part.
