Martin Traverso

> For inline functions we could modify io.trino.metadata.LanguageFunctionManager#addInlineFunction to take function offset (location within query) and use that to calculate locations for function body. That would be ideal, but it...

Can you elaborate on this point? > It is currently unsupported for JDBC connectors. There was an attempt https://github.com/trinodb/trino/pull/19740, but it didn't make it due to reasons (edge cases, fact...

Instead of a dedicated rule to pull a projection above join before pushing down the join into the connector, we should consider adding a generic rule for doing that optimization...

We could make it a cost-aware decision. In practice, joins that explode data (in particular, cross joins that produce significant amount of data) are not that common, though.

> we could have PullProjectionAboveNode Rather, it would be PushXXXBelowProject, and it should generally be done: * for any operation that reduces the amount of data that the projection would...

This was to avoid exposing the dependency on guava, which could cause problems for users that rely on other possibly incompatible versions of that library. Guava is only used internally...

> I did find that it was missing the ability to specify name/description for operation names (or for that matter the mbeans themselves). This is minor IMO for mbeans themselves,...

@cla-bot check

My thought is that we should hard-code the locale in the implementation of those functions and provide alternative versions that take a locale as an argument.

The problems I see in the current implementation are: 1. The locale is not something the user can easily change. There's no mechanism via session properties or language to customize...