I have force-pushed to https://github.com/apache/calcite/pull/2024.
There are now some commits to be merged before 1.24 (hopefully today
or tomorrow) and some to be merged after 1.24.
Can someone give it a final review?
Chunwei,
Please, let's do the 1.24 release sooner rather than later. The
BTW, if use 'externalize', what is the opposite side of it?
Is it `internalize` (which doesn't sound right)? Or call it
"de-externalize"?
-Rui
On Wed, Jul 8, 2020 at 4:02 PM Rui Wang wrote:
> O got it :-)
>
>
> -Rui
>
> On Wed, Jul 8, 2020 at 3:55 PM Julian Hyde wrote:
>
>> Please call it
O got it :-)
-Rui
On Wed, Jul 8, 2020 at 3:55 PM Julian Hyde wrote:
> Please call it 'externalize'. 'Serialize' gives some folks PTSD. :)
>
> On Wed, Jul 8, 2020 at 2:26 PM Rui Wang wrote:
> >
> > Thanks everyone for your inputs. Now it sounds like RexNode serialization
> > is not an easy
Please call it 'externalize'. 'Serialize' gives some folks PTSD. :)
On Wed, Jul 8, 2020 at 2:26 PM Rui Wang wrote:
>
> Thanks everyone for your inputs. Now it sounds like RexNode serialization
> is not an easy effort (e.g. as easy as making classes implement
> Serializable). I will log a JIRA to
Thanks everyone for your inputs. Now it sounds like RexNode serialization
is not an easy effort (e.g. as easy as making classes implement
Serializable). I will log a JIRA to document people's opinions.
Currently I am leaning to add serialize()/deserialize() methods to RexNode,
and also see if we
Serializabilty is not very popular in Java right now. There are a
bunch of concerns, including security. Serializable classes are very
brittle, because it's very easy to add a non-serializable field value
in a sub-class.
I strongly favor externalizing over serialization. Convert RexNode to
a
Add something like this to SqlLibraryOperators:
@LibraryOperator(libraries = {POSTGRESQL})
public static final SqlFunction LENGTH = ...;
and create your JDBC connection with 'fun=postgresql'.
LENGTH is not part of the SQL standard, so it should not be in
SqlStdOperatorTable.
Nor should you
Hi,
Is there a mechanism to add/register additional standard operators to be
used by Calcite when defining a model for a JDBC connection? I had hoped
that annotating new functions with LibraryOperator(libraries={STANDARD})
would work but it doesn't seem to be the case, or I'm doing it
Ruben Q L created CALCITE-4113:
--
Summary: Support LEFT join in EnumerableMergeJoin
Key: CALCITE-4113
URL: https://issues.apache.org/jira/browse/CALCITE-4113
Project: Calcite
Issue Type: New
Jiatao Tao created CALCITE-4112:
---
Summary: Better judgment "config.forceDecorrelate" in
DecorrelateProgram
Key: CALCITE-4112
URL: https://issues.apache.org/jira/browse/CALCITE-4112
Project: Calcite
In CALCITE-2450, we proposed a change to normalize the RexNode, and there is a
discussion[1], the change is in very early phrase and the normalization
pattern is unstable.
There is actually no common consensus about what a form (or pattern) a desired
normalization should be:
• People may
11 matches
Mail list logo
