BigQuery's unnest function implementation overrides and breaks this function for other dialects

[altvod]

If bigquery is installed, the unnest function (defined here) overrides the unnest function for all dialects.

In PostgreSQL usage of unnest is allowed with column identifiers (unnesting an array contained in a table column). But the global re-definition of unnest caused by bigquery makes code like this sa.func.unnest(some_column) fail with TypeError: The argument to unnest must have an ARRAY type. because, obviously, a column is not an array literal.

In my case I really do need many dialects installed at the same time.

[altvod]

The best fix I can think of is to move the logic from this class to the visitor that renders functions in the BQ dialect implementation

[chalmerlowe]

Sorry to hear that you are running into this issue. Thank you submitting this bug/feature request.

If you happen to have code OR a patch that you would like to submit to address this issue feel free to submit a PR.

In the meantime, I will consider this feature request and explore where it should fit in our priority list based on current staffing and workloads.

[fordhoka]

Is there an ETA on this? This is complicating our upgrade to sqlalchemy 2.

In case this helps anyone else experiencing this issue, our workaround was to always unregister the unnest function before connecting to postgresql and then always register it again before connecting to bigquery.

[r1b]

Is deprecation acceptable? Couple of options I was poking at:

1. Set package = "bigquery" as described in the docs - implementation moves to sqlalchemy.func.bigquery.unnest
2. Export an unnest wrapper that applies this validation, then returns plain old sqlalchemy.func.unnest - the postgres dialect does something similar for array_agg (link here)

I didn't really see a good way to do this without a deprecation period though - I looked at this suggestion:

#882 (comment)

but it seems like once we're about to render the function, its too late to apply this validation.