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.

Sign up for GitHub

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

Jump to bottom

Tracking: Introduce per-module error type for frontend #2366

Open
5 of 7 tasks
Tracked by #4077
lmatz opened this issue May 7, 2022 · 6 comments
Open
5 of 7 tasks
Tracked by #4077

Tracking: Introduce per-module error type for frontend #2366

lmatz opened this issue May 7, 2022 · 6 comments
Labels
component/frontend Protocol, parsing, binder. type/refactor
Milestone
release-1.8

Comments

@lmatz
Copy link
Contributor

lmatz commented May 7, 2022 •
edited
Loading

As mentioned in #1367.

Tracking:
@lmatz lmatz added type/refactor component/frontend Protocol, parsing, binder. labels May 7, 2022
@TennyZhuang
Copy link
Contributor

#2035 can be tracked in the issue

@lmatz lmatz changed the title Introduce per-crate error type for frontend Tracking: Introduce per-crate error type for frontend May 8, 2022
@likg227
Copy link
Contributor

likg227 commented May 10, 2022 •
edited
Loading

How about OptimizeError?

@lmatz
Copy link
Contributor Author

lmatz commented May 10, 2022

How about OptimizeError?

Maybe an enum of PlanError? It seems the optimization rules return Option instead of Result, similar to Calcite returning a Null in the event of a failure of rule application.

But we will see whether it is necessary later and we can add it then.

@likg227
Copy link
Contributor

likg227 commented May 10, 2022

We do need it to check whether apply can be unnested or not.
#2187 (comment)

@likg227
Copy link
Contributor

likg227 commented May 10, 2022

The reason our current optimizer returns Option is for writting code easily........

@TennyZhuang TennyZhuang mentioned this issue Jun 8, 2022
Merged
3 tasks
@BugenZhao BugenZhao mentioned this issue Jun 10, 2022
Closed
4 tasks
@lmatz lmatz mentioned this issue Jun 13, 2022
Merged
1 task
@BowenXiao1999 BowenXiao1999 mentioned this issue Jun 22, 2022
Merged
3 tasks
@BugenZhao BugenZhao mentioned this issue Jul 22, 2022
Closed
8 tasks
@BugenZhao BugenZhao mentioned this issue Jul 31, 2022
Merged
3 tasks
@xiangjinwu xiangjinwu mentioned this issue Nov 3, 2022
Merged
3 tasks
@xiangjinwu xiangjinwu added this to the next-release-0.1.15 milestone Nov 14, 2022
@BugenZhao BugenZhao changed the title Tracking: Introduce per-crate error type for frontend Tracking: Introduce per-module error type for frontend Feb 26, 2024
@BugenZhao
Copy link
Member

After #14953, I believe there's a stronger motivation for addressing this issue.

@BugenZhao BugenZhao mentioned this issue Feb 26, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component/frontend Protocol, parsing, binder. type/refactor
Projects
None yet
Milestone
release-1.8
Development

No branches or pull requests
6 participants
@lmatz @TennyZhuang @xiangjinwu @BugenZhao @HuaHuaY @likg227