fix: Support PostgreSQL VECTOR LENGTH types in Spanner change streams

[mvanhorn]

Extend the PostgreSQL information-schema parser in TypesUtils to recognize the repository's existing embedding-vector grammar, isolate the array element type, and ignore the vector-length constraint when constructing the Cloud Spanner client Type, consistent with the utility's existing treatment of parameterized lengths. The Spanner change-streams-to-BigQuery template fails during worker setup when a PostgreSQL-dialect table tracked by the change stream contains an embedding-vector column such as real[] VECTOR LENGTH 512.

Convert real[] vector length 512 from PostgreSQL information schema and verify it produces an array of FLOAT32, allowing schema setup for the reported embedding column; Convert a case-varied DOUBLE PRECISION[] VECTOR LENGTH 4 and verify it produces an array of FLOAT64, demonstrating that parsing follows the documented grammar rather than hard-coding the reported input.

Fixes #4120

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enables support for PostgreSQL embedding-vector columns within the Spanner change-streams-to-BigQuery template. By updating the schema parsing utility to recognize and strip vector length constraints, the system can now successfully process tables containing vector data types without failing during worker setup.

Highlights

• PostgreSQL Vector Type Support: Added regex-based parsing to TypesUtils to correctly identify and handle PostgreSQL 'VECTOR LENGTH' types in Spanner change streams.
• Schema Parsing Logic: Updated the information schema parser to isolate the array element type and ignore vector length constraints, ensuring compatibility with Spanner's type system.
• Test Coverage: Expanded unit tests to verify correct type mapping for vector columns and added validation to reject invalid vector length configurations.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request adds support for parsing PostgreSQL vector types (e.g., real[] VECTOR LENGTH 512) and mapping them to Spanner array types in TypesUtils, along with corresponding unit tests. The reviewer suggested using a dummy type name instead of integer in the negative test case to prevent the test from becoming fragile if integer support is added in the future.

[gemini-code-assist]

Using integer as an unsupported type in this test makes it fragile, as integer is a standard PostgreSQL type that might be supported in the future. If support for integer is added, this test will fail. Consider using a completely dummy/unsupported type name (e.g., unsupportedtype) to ensure the test remains robust and future-proof.

Suggested change

	() -> TypesUtils.informationSchemaPostgreSQLTypeToSpannerType("integer[] vector length 4"));
	() -> TypesUtils.informationSchemaPostgreSQLTypeToSpannerType("unsupportedtype[] vector length 4"));