-
Notifications
You must be signed in to change notification settings - Fork 175
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
[FEAT]: sql image_encode and image_resize #2764
[FEAT]: sql image_encode and image_resize #2764
Conversation
…d303/Daft into sql-image-functions-2
…d303/Daft into sql-image-functions-2
…d303/Daft into sql-image-functions-2
CodSpeed Performance ReportMerging #2764 will degrade performances by 51.78%Comparing Summary
Benchmarks breakdown
|
arg, | ||
operator: FunctionArgOperator::Assignment, | ||
} => match name.value.as_ref() { | ||
"w" | "width" => { |
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.
Hmm how would be document this behavior? I'm guessing we're going to need a separate documentation page for SQL (or at least some kind of unified documentation across SQL and Python expressions) in which we should also document the argument naming behavior?
…image-functions-2
…image-functions-2
…image-functions-2
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.
Left some comments
} | ||
|
||
#[typetag::serde] | ||
impl ScalarUDF for ImageEncode { |
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.
Not relevant to this PR but why do we call this ScalarUDF
when it is not user defined? Might be a good item to change when we clean up our expressions during clean up week.
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.
the idea was that they are "user defined", but these initial ones are managed by us. Eventually exposing an interface for third party udfs using the same underlying system.
SQLExpr::Tuple(_) => unsupported_sql_err!("TUPLE"), | ||
// Similar to rust and python conventions, tuples always have a fixed size, | ||
// so we convert them to a fixed size list. | ||
SQLExpr::Tuple(exprs) => { |
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.
How are tuples in SQL used? As in, do we have a supported SQL query/expression using tuples right now? Just curious
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.
yes, this here updates our sql support to include support for tuples.
you can use them anywhere exprs are accepted now.
fsl_from_sql = daft.sql_expr('(1, 2, 3)')
this is the functional equivalent of
fsl_from_python = daft.lit(
(1, 2, 3)
).cast(daft.DataType.fixed_size_list(daft.DataType.int64(), 3))
Feel free to merge once you make all the requested changes btw |
depends on #2757