For the purposes of showing what PartiQL Shape could potentially look like, I've written this POC. Some of the prevalent aspects of this POC include:
Parameterization of our runtime types. AKA NUMERIC(5, 1) and CHARACTER(10).
Defining PartiQLShape as a wrapper over a runtime type to additionally hold Constraints and Metas that help with output type inference.
Defining Constraints such as SQL's NOT NULL and ISL's ANY OF, ELEMENT, and FIELDS constraints.
At this stage of the POC, PartiQL Shape has been able to successfully replace StaticType with all of the PlanTyperTestsPorted. The function outcome tests are failing (due to lack of support for nullable types, but that is a quick fix).
What is the impact?
We now can fully conform to SQL:1999 with parameterized types. Also, our type semantics can also match what SQL:1999 prescribes. Gone are the days of converting StaticType to a runtime type for function resolution -- this had many issues. We now just use the runtime type directly for function resolution -- why wouldn't we? Also, we now support nullable types -- the lack of this also previously caused issues with type inference, function resolution, and aggregate function resolution. We've fully supported the DYNAMIC type and have made the distinction from the ALL type clear. ALL is now gone.
What is next?
There is a lot to go, namely:
I need to clean up a lot of code. Just a fair warning.
Reworking all function signatures to use the new PartiQLType (rather than transforming the old definitions)
Figuring out how the PartiQLShapeSystem comes into play (how do we make sure that all relevant constraints/metas are added appropriately)
There are several scrappy parts of the code that I'd like to consolidate under this system (but for this demonstration, I didn't have time to flush it out)
Figuring out what Metas are (in contrast to Constraints)
Fleshing out the CastTable (I've only implemented a portion of it). All details are written explicitly in SQL:1999, however, it is tedious to write out prior to demonstrating this.
How can I (the reviewer) read this PR?
Well, I'd first take a look at package org.partiql.shape under the partiql-types sub-project. You may see many similarities to Ion Schema -- as it was used as a guide in several situations. I'd also look at org.partiql.value under the same sub-project to see the new runtime types.
Other Information
Updated Unreleased Section in CHANGELOG: [YES/NO]
< If NO, why? >
Any backward-incompatible changes? [YES/NO]
< If YES, why? >
< For this purpose, we define backward-incompatible changes as changes that—when consumed—can potentially result in
errors for users that are using our public APIs or the entities that have public visibility in our code-base. >
Any new external dependencies? [YES/NO]
< If YES, which ones and why? >
< In addition, please also mention any other alternatives you've considered and the reason they've been discarded >
THIS IS A DRAFT
Description
Overview
For the purposes of showing what PartiQL Shape could potentially look like, I've written this POC. Some of the prevalent aspects of this POC include:
NUMERIC(5, 1)andCHARACTER(10).PartiQLShapeas a wrapper over a runtime type to additionally holdConstraintsandMetasthat help with output type inference.Constraintssuch as SQL'sNOT NULLand ISL'sANY OF,ELEMENT, andFIELDSconstraints.At this stage of the POC, PartiQL Shape has been able to successfully replace StaticType with all of the PlanTyperTestsPorted. The function outcome tests are failing (due to lack of support for nullable types, but that is a quick fix).
What is the impact?
We now can fully conform to SQL:1999 with parameterized types. Also, our type semantics can also match what SQL:1999 prescribes. Gone are the days of converting
StaticTypeto a runtime type for function resolution -- this had many issues. We now just use the runtime type directly for function resolution -- why wouldn't we? Also, we now support nullable types -- the lack of this also previously caused issues with type inference, function resolution, and aggregate function resolution. We've fully supported theDYNAMICtype and have made the distinction from theALLtype clear.ALLis now gone.What is next?
There is a lot to go, namely:
Metasare (in contrast toConstraints)CastTable(I've only implemented a portion of it). All details are written explicitly in SQL:1999, however, it is tedious to write out prior to demonstrating this.How can I (the reviewer) read this PR?
Well, I'd first take a look at package
org.partiql.shapeunder thepartiql-typessub-project. You may see many similarities to Ion Schema -- as it was used as a guide in several situations. I'd also look atorg.partiql.valueunder the same sub-project to see the new runtime types.Other Information
Updated Unreleased Section in CHANGELOG: [YES/NO]
Any backward-incompatible changes? [YES/NO]
publicvisibility in our code-base. >Any new external dependencies? [YES/NO]
Do your changes comply with the Contributing Guidelines and Code Style Guidelines? [YES/NO]
License Information
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.