Marc MILLAS Senior Architect +33607850334 www.mokadb.com
On Tue, May 30, 2023 at 7:12 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Tue, May 30, 2023 at 8:53 AM Marc Millas <marc.mil...@mokadb.com> wrote > > >> This comes from a prod environment and even casting NULLs (which is more >> than strange, BTW) generates absurd errors. >> > > If you want an input to be anything other than plain text (numbers > partially exempted) you need to cast it. Sure, some limited cases allow > for other parts of a query to infer untyped literals, but literals defined > at the top-level of a SELECT is not one of those places. > > Too my understanding it looks like the parser did not parse the select >> distinct as we think he does. >> > > The DISTINCT clause doesn't really come into play here at all, so if you > think it does you indeed have a misunderstanding. > Inputting literal NULLs, and using DISTINCT, are both, IMO, considered > code smells and seldom used. You still need to be able to interpret error > messages but if you are running actual queries with these things you may > have larger model design and query writing concerns to deal with in > addition to being able to identify the problems specific error messages are > pointing out and trying to fix them. > Hi David, my guess about the distinct syntax was just because if I take the distinct OUT, the SQL works fine. nothing more, nothing less... > > David J. > >
