Re: SQL column names - double quoted
SqlWriterConfig#withQuoteAllIdentifiers does this work.
However, there are some rules that the SqlDialect could control by
themselves,
especially the info from the original SqlIdentifier whether it's quoted or
not which is
parsed from the original sql.
If the SqlNode is constructed from RelNode, the SqlParserPosition is always
quoted[1].
That's why SqlWriterConfig#withQuoteAllIdentifiers does not work for most
of the identifiers
in this case.
There is only one place which does not use the quoted SqlParserPosition[2],
I suppose
it's the reason why the table identifier is not quoted in this case.
[1]
https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L141
[2]
https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/rel/rel2sql/RelToSqlConverter.java#L959
Sandeep N 于2022年5月29日周日 01:17写道：
> For the little experience I have with using Calcite I have learnt that the
> SqlPrettyWriter has a method "withQuoteAllIdentifiers" on its config but
> that seemingly only addresses table names and not column names in the where
> clause. The proposed path from Yanjing addresses columns.
>
> --Sandeep
>
> On Fri, May 27, 2022 at 8:47 AM Julian Hyde
> wrote:
>
> > Can someone remind me - is there an option for the writer to omit quotes
> > on identifiers if they are unnecessary? (This would imply that the writer
> > knows how the target dialect treats case sensitivity.)
> >
> > I may have implemented such a feature at some point. (I forget.) If so it
> > should generate nice-looking sql with a little extra effort configuring
> the
> > writer.
> >
> > Julian
> >
> > > On May 26, 2022, at 19:32, Sandeep N wrote:
> > >
> > > Thank you Yanjing, that fix addressed it.
> > >
> > > --Sandeep
> > >
> > >> On Thu, May 26, 2022 at 5:33 PM Yanjing Wang <
> zhuangzixiao...@gmail.com
> > >
> > >> wrote:
> > >>
> > >> Hi Sandeep,
> > >>
> > >> try select.toSqlString(new
> > >>
> > >>
> >
> AnsiSqlDialect(AnsiSqlDialect.DEFAULT_CONTEXT.withIdentifierQuoteString(""))).getSql().
> > >>
> > >> Sandeep N 于2022年5月27日周五 06:03写道：
> > >>
> > >>> Hi Stamatis,
> > >>>
> > >>> Thanks for the quick response, I tried your suggestion as follows
> > >>>
> > >>> RelToSqlConverter converter = new RelToSqlConverter(new
> > >>>
> > >>>
> > >>
> >
> AnsiSqlDialect(AnsiSqlDialect.DEFAULT_CONTEXT.withIdentifierQuoteString("")));
> > >>> SqlSelect select = converter.visitRoot(relNode).asSelect();
> > >>> SqlWriterConfig config = SqlPrettyWriter.config().
> > >>>withCaseClausesOnNewLines(false).
> > >>>withQuoteAllIdentifiers(false);
> > >>> System.out.println(new SqlPrettyWriter(config).format(select));
> > >>>
> > >>> and I still get this
> > >>> SELECT "a"
> > >>> FROM test_table
> > >>> WHERE "b" = 'value';
> > >>>
> > >>> It is not obvious to me as to what I am doing wrong. Is the above
> block
> > >> of
> > >>> code the only pieces that I need to put in play to get that sql
> > >> generated?
> > >>>
> > >>> --Sandeep
> > >>>
> > >>> On Thu, May 26, 2022 at 2:22 PM Stamatis Zampetakis <
> zabe...@gmail.com
> > >
> > >>> wrote:
> > >>>
> > Hi Sandeep,
> >
> > If you want to turn off quoting (which I am not sure if it is a good
> > >>> idea)
> > when you go from relational algebra to SQL you have to customize the
> > SqlDialect that you are using via Context#withIdentifierQuoteString
> > >> [1].
> > You can find a small example as part of RelToSqlConverterTest here
> > [2].
> >
> > Best,
> > Stamatis
> >
> > [1]
> >
> >
> > >>>
> > >>
> >
> https://github.com/apache/calcite/blob/9bdfd9a178f493b235d8785afd94fd0c998e8cce/core/src/main/java/org/apache/calcite/sql/SqlDialect.java#L1408
> > [2]
> >
> >
> > >>>
> > >>
> >
> https://github.com/zabetak/calcite/commit/ea18d28f4fb44113c414c393fe28fc94b3eecc29
> >
> > On Thu, May 26, 2022 at 9:18 PM Sandeep N >
> > wrote:
> >
> > > Hi all,
> > >
> > > I am pretty aware that this question may have been asked before as
> I
> > >>> have
> > > found references on stackoverflow but have yet to stumble on a
> > >> response
> > > which lays out the path on solving this.
> > >
> > > Here is the problem I am facing -
> > > I am using relational algebra to generate SQL on a table test_table
> > >>> with
> > > two columns a and b fed into the calcite Framework (see below) via
> a
> > custom
> > > catalog. Both a and b are varchar columns.
> > >
> > > FrameworkConfig config = Frameworks.newConfigBuilder().
> > >parserConfig(SqlParser.Config.DEFAULT).
> > >defaultSchema(addSchemas(rootSchema, schemaName,
> > schema)).
> > > <--- this is where I plug my custom table.
> > >traitDefs((List) null).
> > >operatorTable(sqlOperatorTable).
> > >
> > >>
Re: [DISCUSS] not equal operator vs less than combining greater than
Hi all,
I've confirmed it.
The reason why different plans for queries:
query 1:
select * from "emps" where "name" <> '' and "name" <> '3'
query 2:
select * from "emps" where ("name" > '' or "name" < '') and ("name" > '3'
or "name" < '3')
is not from the operator consistency.
It's just because the expression: ("name" > '' or "name" < '') and ("name"
> '3'
or "name" < '3') cannot be translated into Sarg for now.
I'll file a Jira issue to track and improve this.
Benchao Li 于2022年5月28日周六 09:30写道：
> FYI, the issue might be this one:
> https://issues.apache.org/jira/browse/CALCITE-4993
>
> I also looked into this in this direction yesterday, however, I didn't
> confirm it yet.
> That's why I didn't reply to this email before. I will do further
> verifications and
> post the result here later.
>
>
>
> Julian Hyde 于2022年5月27日周五 23:52写道：
>
>> I think there’s a JIRA case for this. The implicit casts prevent SARG
>> simplification from kicking in. In SARG representation the expressions
>> would be the same. Which is why we love SARGs.
>>
>> Julian
>>
>> > On May 26, 2022, at 17:49, Yanjing Wang
>> wrote:
>> >
>> > Hi community,
>> >
>> > I have this sql: select * from "emps" where "name" <> '' and "name" <>
>> '3'
>> >
>> > I thought it would generate the same plan with
>> > select * from "emps" where ("name" > '' or "name" < '') and ("name" >
>> '3'
>> > or "name" < '3')
>> >
>> > but not, the not equal operator consistency is different with less than
>> and
>> > greater than operator,
>> >
>> > which will cause the literal '' and '3' have different data type in
>> plans
>> > of the above sqls.
>> >
>> > That behavior maybe cause some queries will not hit the materialization.
>> >
>> > should we canonize ("name" > '' or "name" < '') and ("name" > '3' or
>> > "name" < '3') to not equal or vice versa as RelToSql
>> > <
>> https://github.com/apache/calcite/blob/9bdfd9a178f493b235d8785afd94fd0c998e8cce/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L870
>> >
>> > behaves?
>>
>
>
> --
>
> Best,
> Benchao Li
>
--
Best,
Benchao Li
[jira] [Created] (CALCITE-5168) Allow AS after parenthesized JOIN
Julian Hyde created CALCITE-5168:
Summary: Allow AS after parenthesized JOIN
Key: CALCITE-5168
URL: https://issues.apache.org/jira/browse/CALCITE-5168
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
In CALCITE-35, we added support for parenthesized join, for example
{code}
SELECT a.x, b.y, c.z FROM a CROSS JOIN (b CROSS JOIN c)
{code}
but the SQL standard and PostgreSQL go further, and allow you to add an alias:
{code}
SELECT a.x, d.y, d.z FROM a CROSS JOIN (b CROSS JOIN c) AS d
{code}
Note that the second query has "AS d" at the end, and "b.y, c.z" in the SELECT
clause has changed to "d.y, d.z". The "d" alias obscures the "b" and "c"
aliases, so "b.y, c.z" would no longer be valid. (If "y" and "z" are not unique
in "d", the new query would be invalid too.)
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
Calcite's oldest bug
CALCITE-35 [1] ("Support parenthesized sub-clause in JOIN") is
probably Calcite's most loved bug: It is nine years old, and has seven
duplicates.
For a long time I thought it was too hard to fix, but I've spent the
last few weeks wrestling with the parser, and I think I have a
solution.
Can some people review the PR [2], test it against queries they think
should work, and make sure that it doesn't break anything. I'd like to
get it into 1.31 if possible.
Julian
[1] https://issues.apache.org/jira/browse/CALCITE-35
[2] https://github.com/apache/calcite/pull/2820
Re: SQL column names - double quoted
For the little experience I have with using Calcite I have learnt that the
SqlPrettyWriter has a method "withQuoteAllIdentifiers" on its config but
that seemingly only addresses table names and not column names in the where
clause. The proposed path from Yanjing addresses columns.
--Sandeep
On Fri, May 27, 2022 at 8:47 AM Julian Hyde wrote:
> Can someone remind me - is there an option for the writer to omit quotes
> on identifiers if they are unnecessary? (This would imply that the writer
> knows how the target dialect treats case sensitivity.)
>
> I may have implemented such a feature at some point. (I forget.) If so it
> should generate nice-looking sql with a little extra effort configuring the
> writer.
>
> Julian
>
> > On May 26, 2022, at 19:32, Sandeep N wrote:
> >
> > Thank you Yanjing, that fix addressed it.
> >
> > --Sandeep
> >
> >> On Thu, May 26, 2022 at 5:33 PM Yanjing Wang >
> >> wrote:
> >>
> >> Hi Sandeep,
> >>
> >> try select.toSqlString(new
> >>
> >>
> AnsiSqlDialect(AnsiSqlDialect.DEFAULT_CONTEXT.withIdentifierQuoteString(""))).getSql().
> >>
> >> Sandeep N 于2022年5月27日周五 06:03写道：
> >>
> >>> Hi Stamatis,
> >>>
> >>> Thanks for the quick response, I tried your suggestion as follows
> >>>
> >>> RelToSqlConverter converter = new RelToSqlConverter(new
> >>>
> >>>
> >>
> AnsiSqlDialect(AnsiSqlDialect.DEFAULT_CONTEXT.withIdentifierQuoteString("")));
> >>> SqlSelect select = converter.visitRoot(relNode).asSelect();
> >>> SqlWriterConfig config = SqlPrettyWriter.config().
> >>>withCaseClausesOnNewLines(false).
> >>>withQuoteAllIdentifiers(false);
> >>> System.out.println(new SqlPrettyWriter(config).format(select));
> >>>
> >>> and I still get this
> >>> SELECT "a"
> >>> FROM test_table
> >>> WHERE "b" = 'value';
> >>>
> >>> It is not obvious to me as to what I am doing wrong. Is the above block
> >> of
> >>> code the only pieces that I need to put in play to get that sql
> >> generated?
> >>>
> >>> --Sandeep
> >>>
> >>> On Thu, May 26, 2022 at 2:22 PM Stamatis Zampetakis >
> >>> wrote:
> >>>
> Hi Sandeep,
>
> If you want to turn off quoting (which I am not sure if it is a good
> >>> idea)
> when you go from relational algebra to SQL you have to customize the
> SqlDialect that you are using via Context#withIdentifierQuoteString
> >> [1].
> You can find a small example as part of RelToSqlConverterTest here
> [2].
>
> Best,
> Stamatis
>
> [1]
>
>
> >>>
> >>
> https://github.com/apache/calcite/blob/9bdfd9a178f493b235d8785afd94fd0c998e8cce/core/src/main/java/org/apache/calcite/sql/SqlDialect.java#L1408
> [2]
>
>
> >>>
> >>
> https://github.com/zabetak/calcite/commit/ea18d28f4fb44113c414c393fe28fc94b3eecc29
>
> On Thu, May 26, 2022 at 9:18 PM Sandeep N
> wrote:
>
> > Hi all,
> >
> > I am pretty aware that this question may have been asked before as I
> >>> have
> > found references on stackoverflow but have yet to stumble on a
> >> response
> > which lays out the path on solving this.
> >
> > Here is the problem I am facing -
> > I am using relational algebra to generate SQL on a table test_table
> >>> with
> > two columns a and b fed into the calcite Framework (see below) via a
> custom
> > catalog. Both a and b are varchar columns.
> >
> > FrameworkConfig config = Frameworks.newConfigBuilder().
> >parserConfig(SqlParser.Config.DEFAULT).
> >defaultSchema(addSchemas(rootSchema, schemaName,
> schema)).
> > <--- this is where I plug my custom table.
> >traitDefs((List) null).
> >operatorTable(sqlOperatorTable).
> >
> >> programs(Programs.heuristicJoinOrder(Programs.RULE_SET,
> > true, 2)).build()
> >
> > The relational algebra is then used to generate SQL to the
> >>> AnsiSqlDialect
> > and the resultant output SQL is
> >
> > SELECT "a"
> > FROM test_table
> > WHERE "b" = 'value';
> >
> > I have the SqlWriterConfig setup as such
> >
> > SqlWriterConfig config = SqlPrettyWriter.config().
> >withCaseClausesOnNewLines(false).
> >withQuoteAllIdentifiers(false);
> >
> > I have been trying to figure what needs to change in the sql writer
> >> but
> > after scanning stackoverflow it appears this is controlled by
> > CalciteConnectionConfig and potentially not the SqlWriter. Is this
> > accurate? and if so how do I assemble the right connection config
> >> when
> >>> I
> am
> > building the custom catalog?
> >
> > P.s: I am not parsing SQL but writing directly to the relational
> >>> algebra
> > nodes so SqlParser does not come into play here.
> >
> > Any pointers on how I can go about this is appreciated, say existing
> tests
> > or code which will help me put together a configuration
