Re: Unparsing based on operand type

It’s not possible to do during front-end phases (validation or sql-to-rel) because you don’t yet know what the target dialect is. Not in general anyway; I know that Calcite is often run as a “translation layer”, where there is a single target dialect, but it’s not a clean architecture to make

Re: Unparsing based on operand type

Your first point is a good one. For your second, validation doesn't need dialect knowledge with my suggestion. If the return type of MIN/MAX is inferred to be BOOLEAN, set the unparseOperator. This may or may not get used later, depending on dialect. Tanner On Tue, Jan 23, 2024 at 1:03 PM Mihai

Re: Unparsing based on operand type

I think that unparse is supposed to work even if you haven't validated. Also, validation does not really know about dialects. Mihai From: Tanner Clary Sent: Tuesday, January 23, 2024 1:00 PM To: dev@calcite.apache.org Subject: Re: Unparsing based on operand

Re: Unparsing based on operand type

One idea I had was: during validation when the return type for a call is derived, you could have a property in `SqlBasicCall` called something like "unparseOperator". You could have some logic that determines the value of this operator, and then set it accordingly. Later, during unparsing, you can

Re: Unparsing based on operand type

My guess would be that this is not possible. At the SqlNode level there are no types. Even if there is some type information, it may be wrong or incomplete, since type inference has not been executed yet. I am afraid that even going from RelNode to SqlNode to unparsing won't make this problem

Unparsing based on operand type

Hey Calcite Devs, I'm working on CALCITE-6220 and the summary is that we should unparse MIN/MAX differently for Postgres/Redshift depending on its operand type (if the type is BOOLEAN, it should be rewritten as BOOL_AND/OR). This problem seems