Re: Unparsing based on operand type

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 type >> >> One idea I had was: d

Re: Unparsing based on operand type

e.apache.org > Subject: 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 d

Re: Unparsing based on operand type

parsing won't > make this problem much simpler, although there you can at least count on > the representation being properly typed. > > Mihai > > From: Tanner Clary > Sent: Tuesday, January 23, 2024 12:32 PM > To: dev@calcite.apache.org &

Re: Unparsing based on operand type

parsing won't > make this problem much simpler, although there you can at least count on > the representation being properly typed. > > Mihai > > From: Tanner Clary > Sent: Tuesday, January 23, 2024 12:32 PM > To: dev@calcite.apache.org > Subje

Re: Unparsing based on operand type

much simpler, although there you can at least count on the representation being properly typed. Mihai From: Tanner Clary Sent: Tuesday, January 23, 2024 12:32 PM To: dev@calcite.apache.org Subject: Unparsing based on operand type Hey Calcite Devs, I'm working

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