Yeah, actually, I think I misinterpreted the query now that I had a little more sleep and examined it more closely. No worries, no further help needed.
Thanks! On Mon, Nov 4, 2024 at 5:00 AM Stephen Carlin <scar...@cloudera.com> wrote: > Heh, well it is a flaw in the language design :). I already knew that. > > Ok, I think I have an idea on what I can do at least. You've given me > some good hints. I prolly should look at the SqlNode tree after parsing, > maybe. I'll see what I can do. > > Thanks! > > On Sun, Nov 3, 2024 at 8:26 PM Mihai Budiu <mbu...@gmail.com> wrote: > >> You cannot have the parser use the type information to decide the >> precedence - unless you do type inference during parsing, which no modern >> compiler is doing. Or a very small subset of type analysis, enough to give >> you the information you need. Languages like C, for example, keep different >> symbol tables for type names and other identifiers, so the parser can >> disambiguate dynamically when an identifier is seen whether that's a type >> or a normal identifier. >> >> On the other hand, If your parser has decided what the operator is, then >> you don't have a choice later. >> >> I think you are pointing to a flaw in your language design. You want the >> syntax to accept a superset of the legal programs, then the type analysis >> to throw away illegal programs. >> >> Why do you need two different precedences? Make them the same precedence, >> and then let the type analysis disambiguate. >> >> Mihai >> >> ________________________________ >> From: Stephen Carlin <scar...@cloudera.com.INVALID> >> Sent: Sunday, November 3, 2024 8:15 PM >> To: dev@calcite.apache.org <dev@calcite.apache.org> >> Subject: Re: Operator overloading for SqlSyntax.BINARY >> >> Sigh, I did try making || a function. But when I do, I have two choices, >> neither of which worked: >> >> 1) Make it a "ConcatOr" Function to handle both and defer which one to use >> until RelToSqlConverter. That didn't work because of order of operations. >> The precedence is difference for "or" and "concat". So by the time it hits >> RelToSQlConverter, the precedence has already been decided. >> >> 2) Make 2 different operator functions. Maybe it's possible? But that >> would involve quite a few parser changes to do. I was hoping to keep that >> at a minimum. The SqlBinaryOperator function in Parser.jj is here the >> magic happens and, by the function name, it needs an operator, not a >> function. I even tried changing the Parser.jj file to return an >> SqlOperator instead of an SqlBinaryOperator, but I hit an assertion when >> it >> tried to establish precedence, which has hardcoded "instanceof" >> implementations on how to decide precedence. >> >> The only idea I had was in that filter function I mentioned above. But >> even then...has precedence been decided already? I'm not sure. >> >> I do realize that the syntax we have is a bit strange in terms of operator >> overloading. I do potentially have the option to say "we are not >> supporting the syntax as/is" for the next major implementation, and I >> somehow think that's gonna be the option. But you know users...they like >> backward compatibility. So hoping to avoid that. >> >> Thanks for your input! If you can think of something else, I appreciate >> the help! >> >> On Sun, Nov 3, 2024 at 7:42 PM Mihai Budiu <mbu...@gmail.com> wrote: >> >> > In Calcite type inference happens during validation, much later than >> > syntax checking. >> > So you cannot decide just based on "syntax" which || is being invoked. >> > Moreover, the presence of type casts may make this tricky. Consider true >> > || 'false'. Depending on the implicit casting rules, this may be >> > interpreted either as a Boolean or as a string. >> > But indeed, if you have your own SqlOperatorTable, and given the >> existing >> > implicit casts rules, you should be able to implement your desired >> behavior. >> > >> > I suspect that Calcite indeed is not prepared to disambiguate overloaded >> > operators based on type - only overloaded functions. >> > >> > But since you have your own SqlOperatorTable, can you make || be a >> > function? I think this only may make a difference if you plan to convert >> > the representation back to SQL using RelToSqlConverter - then having it >> be >> > a FUNCTION would cause problems. >> > >> > Note: I haven't tried the solution I am proposing - it may not work. >> > >> > Mihai >> > ________________________________ >> > From: Stephen Carlin <scar...@cloudera.com.INVALID> >> > Sent: Sunday, November 3, 2024 2:57 PM >> > To: dev@calcite.apache.org <dev@calcite.apache.org> >> > Subject: Operator overloading for SqlSyntax.BINARY >> > >> > Hi all, >> > >> > I'm currently trying to implement Calcite on my already existing SQL >> > syntax. I created my own SqlOperatorTable and I overrode the >> > lookupOperatorOverloads method. And things are working pretty well. >> > But.... >> > >> > I have a situation with the "||" operator. In my syntax, it can be >> used as >> > either "concat" or "or". I thought this was gonna be an easy task >> within >> > the framework. According to my syntax rules (for better or for worse), >> if >> > both parameters are boolean, it should be an "or". Otherwise, it >> should be >> > a "concat". >> > >> > My plan was to return both operators in the lookupOperatorOverloads >> > operator list and let the Calcite framework do its thing. That method >> does >> > not have access to the parametrs. But I did see a >> > filterRoutinesByParameterTypeAndName method which would do exactly what >> I >> > want! However, the first check in the method is "is it an >> > SqlSyntax.FUNCTION", which...it is not, it's a BINARY. So I'm unable to >> > use this filter and I don't have a way to choose based on parameters. >> > >> > I have to use 2 different operators because the precedence of OR is 22 >> and >> > CONCAT is 60. >> > >> > I hope this is enough of an explanation of my problem. Any suggestions >> on >> > how to solve this? I have my own Parser.jj that I'm using so I can >> > theoretically manipulate code there, but I'd like to keep manipulations >> > there to a minimum. Also, is there any reason why the filter routine >> only >> > wants to filter functions and not binary operators? >> > >> > Thanks in advance, >> > >> > Steve >> > >> >
