PType Finalization Prior to 1.0

[johnedquinn]

Relevant Issue/Bug

• See #1488

Description

• The issue aims to track two things:
  • That the PType.Kind enum allows for backwards compatible additions. This is required.
  • That the PType public DOM representation be explored and, if appropriate, added (while making PType internal). This would need to make sure that evaluation isn't significantly affected.

Additional Context

Please see the relevant design document for clarification. Reach out to @johnedquinn for more information.

[RCHowell]

Adding a note that we should make ptype constructors private and called via a factory method on the ptype implementation itself. Right now these are in a separate factory which does not make this safe.

[RCHowell]

Should coercions be modeled differently than CAST? Right now we use the type from the function signature to create a CAST which would require defining functions on PType rather than a higher category like TEXT/DECIMAL/etc. I think function signatures should map to what methods are available on the related datum.

For datum, we do not care if it's VARCHAR(10) vs VARCHAR(11) — we only care that we can call getString() -> String so I think it's unnecessary (and complicated). The result however is that we have to modify how we are doing coercions.

See, we want to coerce the input into something that we can call getString() on. Which really means there's a 1:1 between parameter types and datum kind.