Hard Coded Query Type creates Unexpected behaviour

[OTooleMichael]

bigquery-emulator/server/handler.go

Line 1473 in e411226

StatementType: "SELECT",

Upon creating a Job the job type is always set to "SELECT". This causes failure when this is used to gather data about the job just run. For example, if one wants to figure out the number of rows affected by any job, they will look up the stats of destination table if it is SELECT - reporting SELECT when its not can create unexpected behaviour trying to look up a table that doesn't exist.

TBH this issue is just related to DBT which would benefit from being able to use the emulator. The way they execute against BQ causes this to be a critical path. Of note I have a PR with DBT which has a lot of people asking about being able to use this emulator locally, and this seems to be the blocker.

https://github.com/dbt-labs/dbt-bigquery/blob/62695c9322f71339fd0cc839761643244d4d7ad1/dbt/adapters/bigquery/connections.py#L321

I have too suggestions:

1. I imagine that since the ZetaSQLGo module does parse the SQL it should actually know what was run, and that would just need to be surfaced?
2. Alternatively actually settings this to "UNKNOWN" instead of "SELECT" would cause/allow people to handle that this is just a dummy value?

2 doesn't seem great long term, but it would of course be easy and less misleading?