-
Notifications
You must be signed in to change notification settings - Fork 103
feat: provide additional search_path patterns for typechecking #484
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
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.
nice!
a few nits:
- is linter the right place for this? Or rather db settings?
- maybe we can compile the glob already in the settings, and not in every typecheck run?
is linter the right place for this? Or rather db settings?
Hmm had it there at first :D The reason I used the linter in the end was that the search_path only applies to the type checking, and to nothing else DB related. for example, if we use the EXECUTE STATEMENT feature, it'll not use those search paths.
I also fear that there might be a misunderstanding that you "configure the db to use the search_path".
But I don't have a strong opinion on this. What do you prefer?
is linter the right place for this? Or rather db settings?
Hmm had it there at first :D The reason I used the linter in the end was that the search_path only applies to the type checking, and to nothing else DB related. for example, if we use the EXECUTE STATEMENT feature, it'll not use those search paths.
I also fear that there might be a misunderstanding that you "configure the db to use the search_path".
But I don't have a strong opinion on this. What do you prefer?
mhh what do you think of adding a new section into he settings for typechecking? That way, we can also add disable etc. linting and type checking are two different things after all. and the lint settings are used to configure individual rules.
is linter the right place for this? Or rather db settings?
Hmm had it there at first :D The reason I used the linter in the end was that the search_path only applies to the type checking, and to nothing else DB related. for example, if we use the EXECUTE STATEMENT feature, it'll not use those search paths.
I also fear that there might be a misunderstanding that you "configure the db to use the search_path".
But I don't have a strong opinion on this. What do you prefer?mhh what do you think of adding a new section into he settings for typechecking? That way, we can also add disable etc. linting and type checking are two different things after all. and the lint settings are used to configure individual rules.
I think that's a good idea! I'll do it in this PR
done!
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.
nice!
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.
nit: why not passing the entire config struct?
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.
because of a circular dependency: workspace depends on typecheck, typecheck depends on workspace::TypecheckSettings
Uh oh!
There was an error while loading. Please reload this page.
Adds a
Screenshot 2025年08月30日 at 07 54 00 Screenshot 2025年08月30日 at 07 54 13 Screenshot 2025年08月30日 at 07 54 30linter.searchPathPatternsoption where a user can add glob-patterns for additional schemas to be searched when typechecking.