feat(optimizer)!: Annotate type for snowflake SEARCH function

[fivetran-amrutabhimsenayachit]

Annotate type for snowflake SEARCH function.

Documentation:

https://docs.snowflake.com/en/sql-reference/functions/search

[fivetran-amrutabhimsenayachit]

VectorSearch has been implemented for BigQuery. Search was not implemented for it.
(Refer: https://cloud.google.com/bigquery/docs/reference/standard-sql/search_functions#search)

Before adding SEARCH changes:

• BigQuery SEARCHwas "working" in the sense that SQL would parse and regenerate correctly.
• But it was just an opaque function call with no semantic understanding.
• No tests existed- just basic Anonymous function behavior.

After adding SEARCH changes:

• BigQuery SEARCH gained semantic structure and optimization capabilities.
• But exposed parameter routing bugs that weren't visible before.

BigQuery needs the same custom parameter detection logic that Snowflake has for SEARCH.

@georgesittas , do we need to implement parsing for BigQuery SEARCH as well ?

[VaggelisD]

do we need to implement parsing for BigQuery SEARCH as well ?

We must ensure that we don't break its parsing, or for that matter, the parsing of any SEARCH function across all dialects. If it is broken, we can either implement parsing support or remove the FUNCTIONS entry at that dialect.

The reason we focus on that whenever we introduce a new expression is due to this line here, which automatically introduces parsing across all dialects using the function's sql_name i.e it's class name in snake case.

SQLGlot is lenient enough in the regard that any function that is not recognized is stored into an "Anonymous" expression; A new FUNCTIONS entry may disrupt that fallback mechanism in the event that e.g the node has less arguments or the function requires intricate parsing.

[fivetran-amrutabhimsenayachit]

do we need to implement parsing for BigQuery SEARCH as well ?

We must ensure that we don't break its parsing, or for that matter, the parsing of any SEARCH function across all dialects. If it is broken, we can either implement parsing support or remove the FUNCTIONS entry at that dialect.

The reason we focus on that whenever we introduce a new expression is due to this line here, which automatically introduces parsing across all dialects using the function's sql_name i.e it's class name in snake case.

SQLGlot is lenient enough in the regard that any function that is not recognized is stored into an "Anonymous" expression; A new FUNCTIONS entry may disrupt that fallback mechanism in the event that e.g the node has less arguments or the function requires intricate parsing.

For BigQuery, the following still works for SEARCH function:

• SQL parsing and regeneration (roundtrip)
• Basic functionality for end users
• Cross-dialect transpilation

Only thing that might not work properly is : Semantic AST structure for ANALYZER parameter when used alone.

[georgesittas]

Just sanity checking: no other dialect supports SEARCH? With or without the same semantics. It just seems like a pretty common name for a function to not double-check this.

[georgesittas]

The _build_search helper can be simplified further. I'll do it as a follow-up and share here.

[georgesittas]

@fivetran-amrutabhimsenayachit ac97f14.