Thanks @BhargavBhandari90, could you add tests, for both the single and multisite scenarios in db-tables.feature with given eg

    And I run `wp db query "CREATE TABLE xx_wp_posts ( id int );"`
    And I run `wp db query "CREATE TABLE wp_xx_posts ( id int );"`
    And I run `wp db query "CREATE TABLE wp_posts_xx ( id int );"`

and check STDOUT does/doesn't contain xx as appropriate, plus variations of the wildcard in wp db tables '*_posts', with various options etc?!

Hmm, I think the wildcard case needs to be put through the same filtering as the non-wildcard case. This is what I'm using locally (testing single site only and default options only for the moment):

  Scenario: List database tables on a single WordPress install
    Given a WP install
    And I run `wp db query "CREATE TABLE xx_wp_posts ( id int );"`
    And I run `wp db query "CREATE TABLE wp_xx_posts ( id int );"`
    And I run `wp db query "CREATE TABLE wp_posts_xx ( id int );"`

    When I run `wp db tables`
    Then STDOUT should contain:
      """
      wp_users
      wp_usermeta
      wp_posts
      wp_comments
      wp_links
      wp_options
      wp_postmeta
      wp_terms
      wp_term_taxonomy
      wp_term_relationships
      """
    And STDOUT should not contain:
      """
      xx
      """

    When I run `wp db tables --format=csv`
    Then STDOUT should contain:
      """
      wp_users,wp_usermeta,wp_posts,wp_comments,
      """
    And STDOUT should not contain:
      """
      xx
      """

    When I run `wp db tables '*_posts' --format=csv`
    Then STDOUT should be:
      """
      wp_posts
      """
    And STDOUT should not contain:
      """
      xx
      """

    When I run `wp db tables 'wp_post*' --format=csv`
    Then STDOUT should be:
      """
      wp_postmeta,wp_posts
      """
    And STDOUT should not contain:
      """
      xx
      """

Hey @gitlost. I just saw your feedback now. I added test without checking your feedback. I'll make changes according to that.

@gitlost if we are checking default prefix, then wp_xx_posts will be there in output.

And in this case, it should display using wp list tables. But it's not displaying. I am little confused here.

Hmmm. My understanding - this is all without the --all-tables option being set - would be that wp db tables 'wp_*' should only return tables registered to $wpdb, regardless of the wildcard. So wp db tables 'wp_*' and wp db tables should return the same thing.

A real-world example is the woocommerce plugin, which creates quite a few tables (eg woocommerce_order_items, wp_woocommerce_tax_rates etc) but only registers two: woocommerce_payment_tokenmeta and woocommerce_order_itemmeta. So one gets:

$ wp db tables
wp_users
wp_usermeta
wp_posts
wp_comments
wp_links
wp_options
wp_postmeta
wp_terms
wp_term_taxonomy
wp_term_relationships
wp_termmeta
wp_commentmeta
wp_woocommerce_payment_tokenmeta
wp_woocommerce_order_itemmeta

My expectation would be that wp db tables 'wp_woocommerce_*' would give only:

$ wp db tables 'wp_woocommerce_*'
wp_woocommerce_payment_tokenmeta
wp_woocommerce_order_itemmeta

@schlessera have I got this right?!?

One could argue that this breaks BC though, which may be an issue...

@gitlost I got your point.

But in the current solution, it's not showing proper output while we add wildcard.

Let's say we have added a new table named wp_xx_posts.

So if we do wp db tables, it won't show the newly created table as it is not registered to $wpdb.
But if we do wp db tables "*_posts", then it's showing in output.

So this solution needs to improve.

Yes, I think the code needs to be refactored to put the filtering done based on the passed-in $assoc_args in a function (similar to the way the $get_tables_for_glob is at the moment), and then applied whether $args given or not. Note that the current behaviour is broken even without wildcards, for instance:

$ wp db tables wp_nonexistent_table
wp_nonexistent_table

!!!

For BC there might be a case to add an option --restrict-args (or similar) that gives the new behaviour if set, otherwise gives the old behaviour. But this isn't pretty and given the above buggy behaviour probably not a good idea...

All right @gitlost Will try by this weekend. Thank you.

@gitlost Made some changes. Please check.

As discussed with @BhargavBhandari90 in slack (and thanks for all your work so far!), I'm closing this is favor of #4624