Hey 馃憢 I love this library, as it allows me to infer a lot of the types that I otherwise would have to keep in sync with my database structure! One place, where I'm still missing automatic type-inference, is the fn.agg() function.
I don't say that we have to support it for all functions, but we could add them one-by-one, starting with array_agg and first_value - mainly because I use them 馃槅
One interesting topic might be the that PostgreSQL differs between aggregate functions (e.g. array_agg) and window functions (e.g. first_value). As far as I can see from the docs, window-functions require the definition of OVER, whereby it's optional for the aggregate functions.
I see that some of the available functions (like sum) already have a direct fn.sum variant. If the general consent is to leave fn.agg() untyped, I'd propose to add array_agg and first_value as direct functions to fn.
Note: You could say that this is like reopening #31, just that json_agg now is supported 馃槉
Hey 馃憢 I love this library, as it allows me to infer a lot of the types that I otherwise would have to keep in sync with my database structure! One place, where I'm still missing automatic type-inference, is the
fn.agg()function.I don't say that we have to support it for all functions, but we could add them one-by-one, starting with
array_aggandfirst_value- mainly because I use them 馃槅One interesting topic might be the that PostgreSQL differs between aggregate functions (e.g.
array_agg) and window functions (e.g.first_value). As far as I can see from the docs, window-functions require the definition ofOVER, whereby it's optional for the aggregate functions.I see that some of the available functions (like
sum) already have a directfn.sumvariant. If the general consent is to leavefn.agg()untyped, I'd propose to addarray_aggandfirst_valueas direct functions tofn.Note: You could say that this is like reopening #31, just that
json_aggnow is supported 馃槉