• unknown's avatar
    Bug#18462: mysqldump does not dump view structures correctly · c69ba255
    unknown authored
    (The above problem only occurs with -T -- create a separate file for
    each table / view.) This ChangeSet results in correct output of view-
    information while omitting the information for the view's stand-in
    table. The rationale is that with -T, the user is likely interested
    in transferring part of a database, not the db in its entirety (that
    would be difficult as replay order is obscure, the files being named
    for the table/view they contain rather than getting a sequence number).
    
    
    client/mysqldump.c:
      Added missing fclose(). Before, a view's stand-in table would get
      dumped in get_table_structure(), and the file would remain open.
      get_view_structure() would re-open the same file and write to it,
      resulting in garbage.  The way we handle it now, the table-struct
      gets closed, then the opening of the view-struct (same name)
      overwrites it. (The SQL for the view drop-if-exists the table,
      anyway.) If this were not desired and we wanted SQL for the views
      that contains the create for the stand-in table, we'd hand a mode
      to open_sql_file_for_table(), which would feature O_APPEND in
      get_view_structure(), but not in get_table_structure().
    mysql-test/r/mysqldump.result:
      prove mysqldump -T (each item gets its own file) dumps views correctly
    mysql-test/t/mysqldump.test:
      prove mysqldump -T (each item gets its own file) dumps views correctly
    c69ba255
mysqldump.result 120 KB