Add support max_identifier_length session variable

[sthm]

This PR introduces a session variable to report the maximum identifier length of 255 and enforces that limit on identifiers. Previously, the identifier length was unconstrained, so this is a backwards incompatible change.

This PR adds a known-desirable feature #20931.

Motivation

For compatibility reasons (SQL Server Management Studio), its desirable to report this value for clients.

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• This PR includes the following user-facing behavior changes:
  • Breaking change. Limit the identifier length to 255 bytes and introduce the max_identifier_length session variable.

[benesch]

This looks great to me. Can you work with @mjibson/ @jkosh44 to ensure that no one is using identifiers larger than this before we ship this in a release?

@morsapaes also heads up that we should adjust the dbt adapter for this accordingly.

[jkosh44]

SELECT octet_length(name), name FROM
    (SELECT name FROM mz_objects
    UNION ALL
    SELECT name FROM mz_clusters
    UNION ALL
    SELECT name FROM mz_cluster_replicas
    UNION ALL
    SELECT name FROM mz_databases
    UNION ALL
    SELECT name FROM mz_schemas
    UNION ALL
    SELECT name FROM mz_roles
    UNION ALL
    SELECT name FROM mz_columns)
WHERE octet_length(name) > 255;

Should do the trick. I'll post in the release channel to ask the release manager to run this in prod.

EDIT: I added mz_columns.

[jkosh44]

Looks like this won't break any environments: https://materializeinc.slack.com/archives/CTESPM7FU/p1691430142889159?thread_ts=1691420649.092829&cid=CTESPM7FU, so this is good to merge assuming those nightly failures are unrelated.

I'll add a step to the release playbook to check again during the release.

[jkosh44]

so this is good to merge assuming those nightly failures are unrelated.

Though it does look like the Parallel workload tests need to be updated

worker_10 Query failed: CREATE INDEX idx_v12_c25_int_t2_c23_bigint_t2_c7_bigint_t2_c17_bigint_t2_c33_text_t2_c11_int_t2_c6_boolean_t2_c10_int_t2_c16_int_t2_c8_bigint_t2_c2_boolean_t2_c26_smallint_t2_c1_text_t2_c18_int_t2_c22_bigint_t2_c9_smallint_t2_c15_smallint_t2_c4_bigint_t2_c28_text_t2_c27_text_t2_c37_smallint_t2_c24_text_t2_c3_smallint_t2_c12_boolean_t2_c36_boolean_t2_c30_int_t2 ON v12 (c25_int_t2 ASC, c23_bigint_t2 DESC, c7_bigint_t2 ASC, c17_bigint_t2 DESC, c33_text_t2 DESC, c11_int_t2 DESC, c6_boolean_t2 ASC, c10_int_t2 ASC, c16_int_t2 DESC, c8_bigint_t2 ASC, c2_boolean_t2 ASC, c26_smallint_t2 ASC, c1_text_t2 ASC, c18_int_t2 DESC, c22_bigint_t2 DESC, c9_smallint_t2 ASC, c15_smallint_t2 DESC, c4_bigint_t2 DESC, c28_text_t2 DESC, c27_text_t2 ASC, c37_smallint_t2 DESC, c24_text_t2 ASC, c3_smallint_t2 ASC, c12_boolean_t2 DESC, c36_boolean_t2 ASC, c30_int_t2 ASC); {'S': 'ERROR', 'C': '42601', 'M': 'identifier length exceeds 255 bytes', 'P': '14'}
...
pg8000.exceptions.DatabaseError: {'S': 'ERROR', 'C': '42601', 'M': 'identifier length exceeds 255 bytes', 'P': '14'}

[morsapaes]

Thanks for the heads-up, @benesch. Pushed the dbt change in #21044.

[sthm]

Thanks a lot for taking a look, Joe. I've fixed the tests that failed because of too long identifies. The feature benchmark still seems to be failing, but I don't see how I can possibly introduce a regression there.

[jkosh44]

The feature benchmark still seems to be failing, but I don't see how I can possibly introduce a regression there.

@nrainer-materialize @philip-stoev Is that something to worry about?

@sthm as a side note I left column names and aliases in view definitions out of my query above. For column names we can add the mz_columns, but there isn't a good way to extract aliases out of view definitions. I think we're probably fine as it's unlikely someone has an aliases longer than 255 bytes, but just something to keep in mind for the next release.

[philip-stoev]

The feature benchmark failure can be ignored. It is unrelated to the PR at hand.