feat: Parameterize TimestampWithTimeZoneType by precision#28139
Draft
Joe-Abraham wants to merge 1 commit into
Draft
feat: Parameterize TimestampWithTimeZoneType by precision#28139Joe-Abraham wants to merge 1 commit into
Joe-Abraham wants to merge 1 commit into
Conversation
Contributor
Reviewer's GuideParameterizes TimestampWithTimeZoneType by precision while preserving backward compatibility for the default precision and adds tests for interning, type signatures, precision validation, equality, and getObjectValue behavior. File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Parameterizes
TimestampWithTimeZoneTypeby precision, following the same interning/factory pattern already established forTimestampType.TimestampWithTimeZoneTypemoves from a single hardcoded singleton to a static pool of interned instances for precisions0..MAX_PRECISION(12), built once in a static initializer.Adds
createTimestampWithTimeZoneType(int precision)andgetPrecision(). The existingTIMESTAMP_WITH_TIME_ZONEconstant still refers to the same interned p=3 instance, and itsTypeSignatureis unchanged ("timestamp with time zone", no parameter), so existing serialized metadata continues to parse identically.getObjectValue()throwsUnsupportedOperationExceptionfor any non-default precision, sinceSqlTimestampWithTimeZonehas no sub-millisecond representation yet.equalTo/hash/compareToare unchanged in behavior (still millis-only); precision-aware dispatch for those is left for a follow-up.equals/hashCodeswitch from class-based to reference-identity comparison, which is correct now that instances are interned per precision, with no observable change for the default precision (it was already effectively a singleton).Motivation and Context
This is groundwork for full
TIMESTAMP(p) WITH TIME ZONEtype-system support, tracked in #27934. Introducing the interned per-precision instances now — without yet wiring them into the parser/type registry — lets later phases (parsing, function dispatch, connector support) build on a stableTimestampWithTimeZoneTypeAPI instead of bundling the type-model change with those larger changes.Impact
No user-facing or behavioral change for the default precision (
TIMESTAMP WITH TIME ZONE, p=3): the public constant, its type signature, and itsequals/hashCode/getObjectValuebehavior are unchanged from a caller's perspective.createTimestampWithTimeZoneType(p)forp != 3is new API surface, but the resulting instances aren't yet reachable through SQL parsing or the type registry, so they must not be surfaced outsidepresto-common(e.g. returned from a connector's column type) until #27934 lands — instances withp != 3will fail to round-trip throughTypeSignatureserialization since the parser doesn't recognize the"timestamp with time zone(p)"string form yet.Test Plan
Added
TestTimestampWithTimeZoneTypecovering:createTimestampWithTimeZoneType(p)return the same instance; different precisions return distinct instances.TIMESTAMP_WITH_TIME_ZONEconstant is identical tocreateTimestampWithTimeZoneType(3), and its type signature has no parameter.> MAX_PRECISION).getObjectValue()returns aSqlTimestampWithTimeZonefor the default precision, and throwsUnsupportedOperationExceptionfor every non-default precision.Contributor checklist
Release Notes
Summary by Sourcery
Parameterize the TIMESTAMP WITH TIME ZONE type by precision while preserving backward compatibility for the default precision and reference semantics.
New Features:
Enhancements:
Tests: