-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
opt: add more tests for user-defined type dependency tracking #85703
Conversation
The first commit is from #85700. |
2a5d176
to
21fdcd7
Compare
├── SELECT fb FROM t.public.foobars | ||
├── columns: fb:1 | ||
└── dependencies | ||
└── foobars [columns: fb] |
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.
Is it expected that we do not track the dependence on the foobar
type here? Is this safe because we can determine the transitive dependency of v26 -> foobars -> foobar
?
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.
yeah, i think it's safe since it's not directly referenced by the function. I think the bottom line is that everything should still work if workday
is dropped/renamed.
That being said, if the UDF references the table workdays
as an implicit type, then workday
should be a dependency as well. Could you add a test for that as well? Thanks for fixing the formatting!
create-function | ||
├── CREATE FUNCTION f() RETURNS STRING LANGUAGE SQL AS $$SELECT w::STRING FROM t.public.workdays;$$ | ||
└── dependencies | ||
└── workdays [columns: w] |
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.
Similar question as the one I left in views: is it expected that the workday
type is not a dependency here?
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.
Thanks for fixing this!
├── SELECT fb FROM t.public.foobars | ||
├── columns: fb:1 | ||
└── dependencies | ||
└── foobars [columns: fb] |
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.
yeah, i think it's safe since it's not directly referenced by the function. I think the bottom line is that everything should still work if workday
is dropped/renamed.
That being said, if the UDF references the table workdays
as an implicit type, then workday
should be a dependency as well. Could you add a test for that as well? Thanks for fixing the formatting!
21fdcd7
to
f2dc87c
Compare
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.
Reviewed 3 of 4 files at r2, 4 of 4 files at r3, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @chengxiong-ruan, @mgartner, and @rytaft)
This commit updates the expression formatter to format user-defined type dependencies, which were previously omitted. It also adds some additional tests to ensure that user-defined type dependency tracking is working as intended for `CREATE VIEW` and `CREATE FUNCTION`. Release note: None
f2dc87c
to
9fa4b04
Compare
TFTRs! bors r+ |
Build failed (retrying...): |
Build failed (retrying...): |
Build failed (retrying...): |
Build failed: |
bors r+ |
Build failed (retrying...): |
Build failed (retrying...): |
Build failed (retrying...): |
Build succeeded: |
This commit updates the expression formatter to format user-defined type
dependencies, which were previously omitted. It also adds some
additional tests to ensure that user-defined type dependency tracking is
working as intended for
CREATE VIEW
andCREATE FUNCTION
.Release note: None
Release justification: This is a test-only change.