Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue #2213 - PostgreSQL: Strict typing requires explicit type casts #2234

Open
wants to merge 252 commits into
base: develop
Choose a base branch
from

Conversation

homedirectory
Copy link
Contributor

@homedirectory homedirectory commented Apr 12, 2024

Resolve #2213

Summary of changes:

  • Specific SQL transformations for PostgreSQL as described in the issue.
  • Intermediate EQL transformation now receive not only the runtime DB version but whole domain metadata.
  • General improvements to intermediate EQL data structures: runtime assertions, increased immutability, improved readability, reduced usage of nulls.
  • Documentation of various EQL components.
  • Some changes and enhancements to StreamUtils, requires tg-libs to be recompiled.

A canonical representation serves as a reference, thus it is written in
a human-readable form.
This also includes complex ones, such as caseWhen.
Introduce a separate rule for "like" operators and replace inheritance
relationship by alternation between quantified and comparison operators.
…building it

This gives us more control over the BNF representation which will assist
with the transformation into ANTLR grammar format (among other ones).
This is to avoid 2 placeholder types from different contexts
being accidentally considered equal.
- Add documentation
- Implement toString() methods to facilitate reasoning
- Reduce visibility of PropType constructor (static method should be used)
…ions

This is achieved by casting the NULL to the type of the other operand
In general, this approach of asserting that an exception is thrown is
far from the best because it ignores potential exceptions that may be
thrown for unexpected reasons. Being more specific and expecting only a
certain type of exceptions doesn't work either since the exception gets
rethrown at some higher level, effectively becoming a cause of another
exception. Should we be making assertions about the stack trace at this
point? I don't think so.
The converstion itself was also slightly modified:
* Use an unbounded VARCHAR by default instead of setting the limit to
  255 chars, which has no clear basis.
* Optimise for Integers by limiting the VARCHAR length to 10 chars.
And for all DB back-ends, not just PostgreSQL and SQL Server.
… with string type

Wheels of EQL3 are turning so the workaround is no longer needed.
Moreover, we can now be confident that the null type is never taken for
the string type by mistake, which is vastly important for PostgreSQL.
* Use a sealed interface with inner classes to facilitate pattern
  matching with switch.
* Instead of inserting type casts conditionally, depending on the
  database, always insert them. The conditional approach likely relied
  on implicit type conversion performed by some DBs. Although,
  endAsInt() worked correctly only with H2, which had gone unnoticed as
  its usage has been scarce.
This assertion reports list contents in case of failure.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

PostgreSQL: Strict typing requires explicit type casts
2 participants