Deprecate `FunctionModule` and move functions to `ExpressionBuilder`

[koskimas]

Should we deprecate the function module under expression builder and just merge all functions to the expression builder? So instead of eb.fn.whatever() the user would call eb.whatever()?

We'd still probably want to to have the global function module in db.fn though.

Any thoughts @igalklebanov?

[igalklebanov]

Hey 👋

Sounds good to me from a usability perspective.

Does eb.fn(name, args) still stick around? and eb.fn.agg(name, args)?

Could we help users transition with a script? Would be amazing for bigger projects. We can test against Immich/Bluesky's public repositories.

[koskimas]

Or maybe eb.fn(name, args) and eb.agg(name, args)? agg can be hard to find though...

[igalklebanov]

I wonder if we should merge agg into fn and call it a day. Yeah agg has the extra downstream builders, so what. 🤔

[koskimas]

That's a very good point!

[koskimas]

Also, instead of having a global function module, should we have a global expression builder? Did you suggest that at one point?

[fcanmekikoglu]

lately I'm trying to add methods toeb.fn What I trying to achieve is to add PostGIS methods to it so I can use them like eb.fn.st.dWithin(...args[]) instead of eb=> ST(eb).dWithin(...args[]) or eb.fn<boolean>("ST_DWithin", ...args[])

as far as I learned from discord and docs, there are two workaround for this, module augmentation and patching the package with pnpm.

I don't know the specifics of FunctionModule and how it differs from ExpressionBuilder or ExpressionWrapper but ability to add custom methods to eb.fn would be a great DX feature. I'm writing this here because I know Kysely don't need a gis support, we need to be able to extend some stuff, thats all. If we can have a structure like this, community can distribute their packages/plugins for any extension for any database in a type-safe manner.