[jira] [Commented] (CALCITE-6315) Support PostgreSQL TO_CHAR, TO_DATE, TO_TIMESTAMP
[ https://issues.apache.org/jira/browse/CALCITE-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829994#comment-17829994 ] Jerin John commented on CALCITE-6315: - Hi [~njordan], I am also currently working on a ticket [CALCITE-6269|https://issues.apache.org/jira/browse/CALCITE-6269] to fix some of these FormatElements from BigQuery which are broken or missing in the current implementation. Looking at this list you commented I see many overlaps which can be enabled for Postgres as well, I'll share that PR here once its ready so you can verify and add the remaining missing ones. > Support PostgreSQL TO_CHAR, TO_DATE, TO_TIMESTAMP > - > > Key: CALCITE-6315 > URL: https://issues.apache.org/jira/browse/CALCITE-6315 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Priority: Minor > > PostgreSQL supports different format strings than the version we have > implemented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6315) Support PostgreSQL TO_CHAR, TO_DATE, TO_TIMESTAMP
[ https://issues.apache.org/jira/browse/CALCITE-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829930#comment-17829930 ] Julian Hyde commented on CALCITE-6315: -- OK, great, make sure that it tests all format elements. > Support PostgreSQL TO_CHAR, TO_DATE, TO_TIMESTAMP > - > > Key: CALCITE-6315 > URL: https://issues.apache.org/jira/browse/CALCITE-6315 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Priority: Minor > > PostgreSQL supports different format strings than the version we have > implemented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6315) Support PostgreSQL TO_CHAR, TO_DATE, TO_TIMESTAMP
[ https://issues.apache.org/jira/browse/CALCITE-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829925#comment-17829925 ] Norman Jordan commented on CALCITE-6315: There is already a test for `to_char` with PostgreSQL. [https://github.com/apache/calcite/blob/main/babel/src/test/resources/sql/postgresql.iq#L66] > Support PostgreSQL TO_CHAR, TO_DATE, TO_TIMESTAMP > - > > Key: CALCITE-6315 > URL: https://issues.apache.org/jira/browse/CALCITE-6315 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Priority: Minor > > PostgreSQL supports different format strings than the version we have > implemented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6338) RelMdCollation#project can return an incomplete list of collations in the presence of aliasing
[
https://issues.apache.org/jira/browse/CALCITE-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L updated CALCITE-6338:
---
Description:
{{RelMdCollation#project}} can return an incomplete list of collations.
Let us say we have a Project (or a Calc) that projects the following
expressions (notice that $2 will become $1 and $2 after the projection): $0,
$2, $2, $3
The Project's input has collation [2, 3]
In order to calculate the Project's own collation, {{RelMdCollation#project}}
will be called, and a MultiMap targets will be computed because, as in this
case, a certain "source field" (e.g. 2) can have multiple project targets (e.g.
1 and 2). However, when the collation is being computed, *only the first target
will be considered* (and the rest will be discarded):
{code}
public static @Nullable List project(RelMetadataQuery mq,
RelNode input, List projects) {
...
for (RelFieldCollation ifc : ic.getFieldCollations()) {
final Collection integers = targets.get(ifc.getFieldIndex());
if (integers.isEmpty()) {
continue loop; // cannot do this collation
}
fieldCollations.add(ifc.withFieldIndex(integers.iterator().next()));
// <-- HERE!!
}
{code}
Because of this, the Project's collation will be [1 3], but there is also
another valid one ([2 3]), so the correct (complete) result should be: [1 3] [2
3]
This seems a minor problem, but it can be the root cause of more relevant
issues. For instance, at the moment I have a scenario (not so easy to reproduce
with a unit test) where a certain plan with a certain combination of rules in a
HepPlanner results in a StackOverflow due to SortJoinTransposeRule being fired
infinitely. The root cause is that, after the first application, the rule does
not detect that the Join's left input is already sorted (due to the previous
application of the rule), because there is a "problematic" Project on it (that
shows the problem described above), which returns only one collation, whereas
the second collation (the one being discarded) is the Sort's collation, so it
would be one that would prevent the SortJoinTransposeRule from being re-applied
over and over.
was:
{{RelMdCollation#project}} can return an incomplete list of collations.
Let us say we have a Project that projects the following expressions (notice
that $2 will become $1 and $2 after the projection): $0, $2, $2, $3
The Project's input has collation [2, 3]
In order to calculate the Project's own collation, {{RelMdCollation#project}}
will be called, and a MultiMap targets will be computed because, as in this
case, a certain "source field" (e.g. 2) can have multiple project targets (e.g.
1 and 2). However, when the collation is being computed, *only the first target
will be considered* (and the rest will be discarded):
{code}
public static @Nullable List project(RelMetadataQuery mq,
RelNode input, List projects) {
...
for (RelFieldCollation ifc : ic.getFieldCollations()) {
final Collection integers = targets.get(ifc.getFieldIndex());
if (integers.isEmpty()) {
continue loop; // cannot do this collation
}
fieldCollations.add(ifc.withFieldIndex(integers.iterator().next()));
// <-- HERE!!
}
{code}
Because of this, the Project's collation will be [1 3], but there is also
another valid one ([2 3]), so the correct (complete) result should be: [1 3] [2
3]
This seems a minor problem, but it can be the root cause of more relevant
issues. For instance, at the moment I have a scenario (not so easy to reproduce
with a unit test) where a certain plan with a certain combination of rules in a
HepPlanner results in a StackOverflow due to SortJoinTransposeRule being fired
infinitely. The root cause is that, after the first application, the rule does
not detect that the Join's left input is already sorted (due to the previous
application of the rule), because there is a "problematic" Project on it (that
shows the problem described above), which returns only one collation, whereas
the second collation (the one being discarded) is the Sort's collation, so it
would be one that would prevent the SortJoinTransposeRule from being re-applied
over and over.
> RelMdCollation#project can return an incomplete list of collations in the
> presence of aliasing
> --
>
> Key: CALCITE-6338
> URL: https://issues.apache.org/jira/browse/CALCITE-6338
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> {{RelMdCollation#project}} can return an incomplete list
[jira] [Commented] (CALCITE-6338) RelMdCollation#project can return an incomplete list of collations in the presence of aliasing
[
https://issues.apache.org/jira/browse/CALCITE-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829792#comment-17829792
]
Ruben Q L commented on CALCITE-6338:
Thanks for the feedback [~julianhyde], I have improved the tests and refactored
the implementation to make it simpler.
> RelMdCollation#project can return an incomplete list of collations in the
> presence of aliasing
> --
>
> Key: CALCITE-6338
> URL: https://issues.apache.org/jira/browse/CALCITE-6338
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> {{RelMdCollation#project}} can return an incomplete list of collations.
> Let us say we have a Project that projects the following expressions (notice
> that $2 will become $1 and $2 after the projection): $0, $2, $2, $3
> The Project's input has collation [2, 3]
> In order to calculate the Project's own collation, {{RelMdCollation#project}}
> will be called, and a MultiMap targets will be computed because, as in this
> case, a certain "source field" (e.g. 2) can have multiple project targets
> (e.g. 1 and 2). However, when the collation is being computed, *only the
> first target will be considered* (and the rest will be discarded):
> {code}
> public static @Nullable List project(RelMetadataQuery mq,
> RelNode input, List projects) {
> ...
> for (RelFieldCollation ifc : ic.getFieldCollations()) {
> final Collection integers = targets.get(ifc.getFieldIndex());
> if (integers.isEmpty()) {
> continue loop; // cannot do this collation
> }
> fieldCollations.add(ifc.withFieldIndex(integers.iterator().next()));
> // <-- HERE!!
> }
> {code}
> Because of this, the Project's collation will be [1 3], but there is also
> another valid one ([2 3]), so the correct (complete) result should be: [1 3]
> [2 3]
> This seems a minor problem, but it can be the root cause of more relevant
> issues. For instance, at the moment I have a scenario (not so easy to
> reproduce with a unit test) where a certain plan with a certain combination
> of rules in a HepPlanner results in a StackOverflow due to
> SortJoinTransposeRule being fired infinitely. The root cause is that, after
> the first application, the rule does not detect that the Join's left input is
> already sorted (due to the previous application of the rule), because there
> is a "problematic" Project on it (that shows the problem described above),
> which returns only one collation, whereas the second collation (the one being
> discarded) is the Sort's collation, so it would be one that would prevent the
> SortJoinTransposeRule from being re-applied over and over.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
