Full charset support will necessicate also changes in the runtime (Enumerable/Bindable operators) in particular when it comes to comparing character data types.
Στις Δευ, 12 Νοε 2018 στις 9:31 π.μ., ο/η Julian Hyde <[email protected]> έγραψε: > Thanks for taking this up, Ted. > > One change that I think would be useful would be deprecating the > SaffronProperties.defaultCharset, .defaultNationalCharset, > .defaultCollationName, .defaultCollationStrength, and making them regular > properties (i.e. in CalciteConnectionProperty). Probably remove “default” > from their names. Then they can be set by each connection, without > modifying a .properties file. > > Julian > > > > > On Nov 9, 2018, at 11:29 PM, Ted Xu <[email protected]> wrote: > > > > +1 for full charset support. > > > > There may be multiple changes to make, not only related to literals but > > also to type system, casts, (jdbc) binary protocols etc. > > > > I'd like to propose some design ideas since I'm from a CJK country and > > we've already tackled most of Calcite's charset issues. > > > > On Thu, Nov 8, 2018 at 3:22 AM Julian Hyde <[email protected]> wrote: > > > >>> I can't remember another database that allows just ISO-8859-1 in simple > >>> string literals. > >>> That makes it very surprising. > >> > >> Try SQL Server on rextester.com <http://rextester.com/>. You need to > >> prefix literals with ’N’, like this: N’привет' > >> > >>> What is the reason for Calcite to enforce ISO-8859-1 by default? > >>> > >>> In other words, I can't imagine a project that would pick ISO-8859-1 > as a > >>> default string literal encoding if they HAVE to make an explicit choice > >>> (e.g. no default within Calcite). > >> > >> I really don’t know. > >> > >> I would very much appreciate if someone took ownership of this issue, > took > >> the time to understand what Calcite does today, document it, understand > >> what the SQL standard says, and make improvements. > >> > >> Julian > >> > >> > >>> On Nov 7, 2018, at 11:08 AM, Vladimir Sitnikov < > >> [email protected]> wrote: > >>> > >>>> The issue is not the encoding of our Java code. The issue is the > >> encoding > >>> of the SQL we process. That SQL may or may not come from Java source > >> files. > >>> > >>> I can't remember another database that allows just ISO-8859-1 in simple > >>> string literals. > >>> That makes it very surprising. > >>> > >>> For instance, https://rextester.com/l/postgresql_online_compiler > allows > >>> <<select 'привет'='привет' >> > >>> > >>> What is the reason for Calcite to enforce ISO-8859-1 by default? > >>> > >>> In other words, I can't imagine a project that would pick ISO-8859-1 > as a > >>> default string literal encoding if they HAVE to make an explicit choice > >>> (e.g. no default within Calcite). > >>> > >>> Vladimir > >> > >> > >
