Using the pre_get_table_charset filter ensures wpdb->col_meta never gets populated

[c0ntax]

I have a non-core table with a binary column that I use for selects and deletes (it's an efficient way to store UUIDs). I've noticed that whenever I attempt to do select from it, WP does a relatively expensive SHOW FULL COLUMNS FROM query, which seems to be uncachable. I've been attempting to use the pre_get_table_charset filter to get around this, but this then caused problems when get_col_charset() runs in the same call. It seems that inside get_table_charset() there is the line $this->col_meta[ $tablekey ] = $columns; which appears to be the only place that col_meta is ever populated. But it wont be populated for that table if you use the hook, so if something like this then runs:

                // If still no column information, return the table charset.
                if ( empty( $this->col_meta[ $tablekey ] ) ) {
                        return $this->table_charset[ $tablekey ];
                }

as it does in get_col_charset() then things just break. col_meta for that table is not populated and neither is table_charset. I'm too stupid to work out the best way to fix this I'm afraid.

[c0ntax]

The following in get_col_length() also seems to make the same assumption that running get_table_charset() will ensure that col_meta is populated:

                if ( empty( $this->col_meta[ $tablekey ] ) ) {
                        // This primes column information for us.
                        $table_charset = $this->get_table_charset( $table );
                        if ( is_wp_error( $table_charset ) ) {
                                return $table_charset;
                        }
                }

                if ( empty( $this->col_meta[ $tablekey ][ $columnkey ] ) ) {
                        return false;
                }