@leahecole do you think this is a breaking change ? I feel like is fine because it still compatible with the previous type, I'm just enhancing to cover other response types when getting query results, which can come as IGetQueryResultsResponse (normal path with jobs.getQueryResults) or IQueryResponse (jobs.query "fast query path).

ooo this is such a good question. I thought about it for a bit and I think you're right - it is backwards compatible - I think it does merit a minor release and not just a patch release though because you are adding functionality - you're just doing so in a way that is backwards compatible.

ooo this is such a good question. I thought about it for a bit and I think you're right - it is backwards compatible - I think it does merit a minor release and not just a patch release though because you are adding functionality - you're just doing so in a way that is backwards compatible.

Do you need to also update the docstring to have an example of this? Or is it going to be the same?

I removed this signature change as was not needed. So I think we don't need updates to the docstring, this is just to fix a behavior that users were already expecting from that method.

this syntax feels absolutely wild to me, a concrete type made from ANDing two interfaces? Should it be IQueryResultsResponse?
Does this blow up if you have fields with equal names but varying types?

I changed it to be an or, so it's more accurate. When using the .query method, the return can be either a IQueryResultsResponse or IQueryResponse, this way all common fields are gonna be in that type by default and if you need an specific type, you can create a type coercion like I show in the system-tests:

• nodejs-bigquery/system-test/bigquery.ts

  Line 346 in bef5262

  it('should query with jobs.query and return all PagedResponse as positional parameters', async () => {

• nodejs-bigquery/system-test/bigquery.ts

  Line 357 in bef5262

  it('should query without jobs.query and return all PagedResponse as positional parameters', async () => {

"this syntax feels absolutely wild to me" that's because it is - you can do some wild and wacky things with typescript 😆

Re Alvaro, I think the OR is probably a better choice