Insert does not work if a table exists in 2 schemas

[nachocases]

Describe the bug
When trying to insert rows from stdin into a table on a mysql DB, if the table exists in 2 schemas, the insert fails with

sq: insert ctx.table failed: failed to create dest table ctxt.table: Error 1050 (42S01): Table 'table' already exists 

To Reproduce
In my case the issue happens with a users table, I'm running a docker compose image of mysql and since there is a default schema performance_schema that contains a users table, I get the error

• create a users table on a development schema
• try running cat users.csv | sq '.data' --insert ctxt.users
• you get the error

Expected behavior

The insert should work since without trying to create the table since it already exists.

sq version

Paste the output of sq version --yaml into the code block below:

# $ sq version --yaml
version: v0.48.5
commit: RELEASE
timestamp: "2025-01-20T02:51:35Z"
latest_version: v0.48.5
host:
  platform: darwin
  arch: arm64
  kernel: Darwin
  kernel_version: 24.2.0
  variant: macOS
  variant_version: "15.2"

Source details

If your issue pertains to a particular source (e.g. a Postgres database),
paste the output of sq inspect --overview --yaml @your_source into the
code block below. You may redact any sensitive fields.

# $ sq inspect --overview --yaml @your_source
handle: "@netcurio_local"
location: mysql://root:xxxxx@localhost/development
name: development
name_fq: def.development
schema: development
catalog: def
driver: mysql
db_driver: mysql
db_product: (Ubuntu) 5.7.30-0ubuntu0.18.04.1 / Linux (aarch64)
db_version: 5.7.30-0ubuntu0.18.04.1
user: root@%
size: 3162112

Logs

n/a

Screenshots

n/a

Additional context

The issue seems to be located (at least on the mysql driver) on the following file/line code

I see 2 potential solutions, either query the INFORMATION_SCHEMA and filtering by schema or instead of doing a comparison for == 1 doing it like >= 1.

While the second solution would be super simple to implement the potential problem is if the table does not exists on the destination schema but if it exists on another schema, we'd bypass the creation of the table. The first approach seems more failproof.