-
-
Notifications
You must be signed in to change notification settings - Fork 214
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
Added the ExtendedType interface #2312
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One weird thing is how this goes against our current type organizational patterns. There is a world where GMS doesn't know anything about type implementations, and Dolt/Postgres initializes an engine with types alongside storage specific serialization and comparison code. I think that could be better in some ways, because the engine wouldn't have to hop back and forth between the prolly and sql layers as often. Better perf and probably less type indirection. That's kind of what ExtendedType does. On the other hand, all of the other types explicitly separate logical and storage layer details. And that's something that doesn't seem much harder than the existing dolt changes outside of typeinfo
and types
which are almost deprecated. GMS could have an extended type for behavioral details, and Dolt could have a similar thing for extending serialization patterns for the same ExtendedTypes. For me it's weird to support both patterns at the same time. That plus skipping semantic resolution are my biggest concerns.
ca84752
to
7d2e976
Compare
This adds the
ExtendedType
interface, which is used within DoltgreSQL to implement PostgreSQL types, as well as in Dolt to properly handle the new type and value serialization.Related PRs: