-
Notifications
You must be signed in to change notification settings - Fork 41
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
refactor: table options #2767
refactor: table options #2767
Conversation
…glaredb into universalmind303/extract-parser
some more prereq work for making the tableoptions more flexible as part of #2744. The `Arbitrary` trait has a cascading effect, so it's kind of all or nothing, and since we can't have `trait TableOptions: Arbitrary` in an object-safe way, it's gotta go.
@tychoish I removed all of the We'll probably want some logic for that conversion at some point, but I think it's just noise right now. |
We'll probably want some logic for that conversion at some point, but I think it's just noise right now. Definitely, it's also a fringe feature that (I think) is a superset of table providers rather than a property of a table provider. Makes sense. |
…GlareDB/glaredb into universalmind303/table-options-refactor
…03/table-options-refactor
…GlareDB/glaredb into universalmind303/table-options-refactor
…GlareDB/glaredb into universalmind303/table-options-refactor
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.
few questions and comments.
I guess this is not a new issue, but the refactoring highlights this issue:
if users specify "COLUMNS" for a datasource that doesn't support them, then we should error, and I think right now we just continue, and that's probably incorrect but it probably should be follow up to this, unless it's easy/obvious to fix.
…03/table-options-refactor
No description provided.