Add PostgreSql TSRANGE/TSTZRANGE support #5297
Draft
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.
👷 🚧 Add some support for TS Range type https://www.postgresql.org/docs/16/rangetypes.html#RANGETYPES-EXAMPLES
Types are mapped to string representations as there is no client side data type such as a range that is compatible (Kotlin ranges only implement open/closed on upper bounds). This is consistent with JSON, TSVECTOR types and uses OTHER type to bind the literal value for INSERTS and String for results (Ideally there would be a type mapping for the PostgreSql JDBC driver to use the PgObject type, however only
PostgreSqlType
is available to map types for both Jdbc/R2dbc ).Note: Bind parameters for ranges must be cast e.g.
Range functions https://www.postgresql.org/docs/16/functions-range.html are used to work with ranges e.g extract lower and upper values to the client types
LocalDateTime
andOffSetDateTime
e.g.Also add basic support for
EXCLUDE
table constraints for range supported indexesMultiRange support (Postgresql 14 or higher)
Allows useful arithmetic on ranges
e.g identify the available time slots that are not occupied by any appointments within a specified time range.
Updated the type resolver precedence order such that a
SqlBinaryExpr
must return aBoolean
if one of the arguments isBoolean
e.g Otherwise
SELECT '2011-01-10'::timestamp <@ '[2011-01-01,2011-03-01)'::tsrange
would resolve as a TimeStamp and not BooleanTODO:
Create issue for PR
Add some more Boolean range tests