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 choose to utilize this "unparseOperator" if it is relevant (e.g. the target dialect is Postgres or Redshift in this example.)
A downside of this is that you're no longer strictly validating, are there other pitfalls? Tanner On Tue, Jan 23, 2024 at 12:52 PM Mihai Budiu <mbu...@gmail.com> wrote: > 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 much simpler, although there you can at least count on > the representation being properly typed. > > Mihai > ________________________________ > From: Tanner Clary <tannercl...@google.com.INVALID> > Sent: Tuesday, January 23, 2024 12:32 PM > To: dev@calcite.apache.org <dev@calcite.apache.org> > Subject: Unparsing based on operand type > > Hey Calcite Devs, > > I'm working on CALCITE-6220 > <https://issues.apache.org/jira/browse/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 simple enough, but I've been having trouble deriving the > operand type during unparsing, which has me wondering whether there's a > better place for this translation to occur. My second thought was that this > could occur in StandardConvertletTable but this does not account for the > case where the incoming dialect is NOT Redshift/Postgres (but the target > dialect is.) > > With that being said, my question is: where should this translation occur > (a.k.a. where can I properly access the operand type in order to decide > what the call should be unparsed as)? > > Thanks as always, > Tanner >
