[jira] [Updated] (CALCITE-1928) Calling previous() on a ResultSet that came from an Array gives NullPointerException
[ https://issues.apache.org/jira/browse/CALCITE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1928: - Fix Version/s: avatica-1.11.0 > Calling previous() on a ResultSet that came from an Array gives > NullPointerException > > > Key: CALCITE-1928 > URL: https://issues.apache.org/jira/browse/CALCITE-1928 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > Fix For: avatica-1.11.0 > > > Calling previous() on a ResultSet that came from an Array gives > NullPointerException. I broke this when I committed CALCITE-1902 and changed > 'Helper.INSTANCE' to 'statement.connection.helper', forgetting that > 'statement' can be null. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1902) ResultSet.previous() throws UnsupportedOperationException, but should throw SQLFeatureNotSupportedException
[ https://issues.apache.org/jira/browse/CALCITE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114971#comment-16114971 ] Julian Hyde edited comment on CALCITE-1902 at 8/4/17 9:11 PM: -- You're right. My bad. I logged CALCITE-1928, and I'll fix it. was (Author: julianhyde): You're right. My bad. I logged https://issues.apache.org/jira/browse/CALCITE-1928, and I'll fix it. > ResultSet.previous() throws UnsupportedOperationException, but should throw > SQLFeatureNotSupportedException > --- > > Key: CALCITE-1902 > URL: https://issues.apache.org/jira/browse/CALCITE-1902 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: 1.10.0 >Reporter: Sergio Sainz >Assignee: Sergio Sainz >Priority: Minor > Fix For: avatica-1.11.0 > > > boolean java.sql.ResultSet.previous() throws SQLException should throw > SQLException, but it is throwing UnsupportedOperationException instead. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1902) ResultSet.previous() throws UnsupportedOperationException, but should throw SQLFeatureNotSupportedException
[ https://issues.apache.org/jira/browse/CALCITE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114971#comment-16114971 ] Julian Hyde commented on CALCITE-1902: -- You're right. My bad. I logged https://issues.apache.org/jira/browse/CALCITE-1928, and I'll fix it. > ResultSet.previous() throws UnsupportedOperationException, but should throw > SQLFeatureNotSupportedException > --- > > Key: CALCITE-1902 > URL: https://issues.apache.org/jira/browse/CALCITE-1902 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: 1.10.0 >Reporter: Sergio Sainz >Assignee: Sergio Sainz >Priority: Minor > Fix For: avatica-1.11.0 > > > boolean java.sql.ResultSet.previous() throws SQLException should throw > SQLException, but it is throwing UnsupportedOperationException instead. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CALCITE-1928) Calling previous() on a ResultSet that came from an Array gives NullPointerException
[ https://issues.apache.org/jira/browse/CALCITE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-1928: - Component/s: avatica > Calling previous() on a ResultSet that came from an Array gives > NullPointerException > > > Key: CALCITE-1928 > URL: https://issues.apache.org/jira/browse/CALCITE-1928 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde > > Calling previous() on a ResultSet that came from an Array gives > NullPointerException. I broke this when I committed CALCITE-1902 and changed > 'Helper.INSTANCE' to 'statement.connection.helper', forgetting that > 'statement' can be null. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1928) Calling previous() on a ResultSet that came from an Array gives NullPointerException
Julian Hyde created CALCITE-1928: Summary: Calling previous() on a ResultSet that came from an Array gives NullPointerException Key: CALCITE-1928 URL: https://issues.apache.org/jira/browse/CALCITE-1928 Project: Calcite Issue Type: Bug Reporter: Julian Hyde Assignee: Julian Hyde Calling previous() on a ResultSet that came from an Array gives NullPointerException. I broke this when I committed CALCITE-1902 and changed 'Helper.INSTANCE' to 'statement.connection.helper', forgetting that 'statement' can be null. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1906) JdbcSortRule has a bug and it is never chosen
[
https://issues.apache.org/jira/browse/CALCITE-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114966#comment-16114966
]
Luis Fernando Kauer commented on CALCITE-1906:
--
Debugging some more about this problem, I found out that what makes the sort be
pushed is replacing the trait with the collations with a Collations.EMPTY trait:
{code}
convert(sort.getInput(), traitSet.replace(RelCollations.EMPTY))
{code}
The problem is that SortRemoveRule matches and it is applied when there is an
active RelCollationTraitDef, removing Sort and setting the collation for the
sort input. Maybe JdbcTableScan was supposed to use the collation information,
but it doesn't.
When using the code above to remove collations, SortRemoveRule is not applied
and that's why the sort gets pushed to the database.
And the EnumerableLimitRule extracts the fetch and limit from Sort and it also
is not applied when there is no collation field in the Sort. So the code above
also prevents this rule from being applied.
If it can't assure that the table is sorted the best to do is to remove the
collations when converting to JdbcSort.
> JdbcSortRule has a bug and it is never chosen
> -
>
> Key: CALCITE-1906
> URL: https://issues.apache.org/jira/browse/CALCITE-1906
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Luis Fernando Kauer
>Assignee: Julian Hyde
>
> JdbcSortRule tries to push sort and limit operations to the database.
> Currently offset and limit operations are explicitly not pushed to the
> database (prevented by the rule) but even sort operations end up not being
> pushed.
> Checking how other adapters deal with this, like Mongo and Cassandra
> adapters, I realized that the convert function from JdbcSortRule is different
> from the others.
> Jdbc-adapter:
> {code}
> if (sort.offset != null || sort.fetch != null) {
> // Cannot implement "OFFSET n FETCH n" currently.
> return null;
> }
> final RelTraitSet traitSet = sort.getTraitSet().replace(out);
> return new JdbcSort(rel.getCluster(), traitSet,
> convert(sort.getInput(), traitSet), sort.getCollation());
> {code}
> mongodb-adapter:
> {code}
> final RelTraitSet traitSet =
> sort.getTraitSet().replace(out)
> .replace(sort.getCollation());
> return new MongoSort(rel.getCluster(), traitSet,
> convert(sort.getInput(), traitSet.replace(RelCollations.EMPTY)),
> sort.getCollation(), sort.offset, sort.fetch);
> {code}
> By fixing JdbcSortRule so that it is just like those others and by removing
> the code that prevented the rule to match when limit or offset are used seems
> to solve the problem and JdbcSortRule now is being applied and both sort and
> limit are being pushed to the database.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1927) Mapping for Types.BIT: boolean or BitSet?
[
https://issues.apache.org/jira/browse/CALCITE-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114944#comment-16114944
]
Julian Hyde commented on CALCITE-1927:
--
To keep this simple, remember we're just considering the driver, not the
database. The database prepares the query and knows that it has a column whose
type is say, BIT(21), and tells that to Avatica.
> Mapping for Types.BIT: boolean or BitSet?
> -
>
> Key: CALCITE-1927
> URL: https://issues.apache.org/jira/browse/CALCITE-1927
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.13.0
>Reporter: Vladimir Sitnikov
> Labels: pgjdbc, postgresql
>
> Currently Avatica implements `Types.BIT` as `Boolean` (see
> https://github.com/apache/calcite-avatica/blob/4db1fb9c66db8ccebc9e96ce678154ec69c557f0/core/src/main/java/org/apache/calcite/avatica/AvaticaSite.java#L227-L230
> )
> Certain databases (e.g. PostgreSQL) have {{bit\(n)}} and {{varbit\(n)}} data
> types that are "bit strings" (see
> https://www.postgresql.org/docs/9.6/static/datatype-bit.html )
> If both used together, {{getObject}} just blows when trying to convert thing
> like {{'01101'}} to a boolean.
> I wonder what should be the behavior for {{Types.BIT}}.
> The original discussion is here: https://github.com/pgjdbc/pgjdbc/issues/908
> PS. I'm not using Avatica + PostgreSQL + varbit combo yet, however I just
> want to weight different implementation options, and make it simpler for
> different JDBC implementations to talk to each other.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1927) Mapping for Types.BIT: boolean or BitSet?
[
https://issues.apache.org/jira/browse/CALCITE-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114766#comment-16114766
]
Vladimir Sitnikov commented on CALCITE-1927:
{quote}If you mean setting the value of a column of type bit(3), then I think
that's straightforward: the driver should just take bits 0, 1 and 2 of
byte[0].{quote}
Afaik, the driver might not know the true width.
For instance:
{code:sql}
create table abc (
v varbit(30)
);
insert into abc(v) values(?);
{code}
There's max width, however it is not clear what number of bits does user want
to create.
Just for the reference:
{noformat}
select b'0'=b'00';
?column?
--
f
test=> select version();
version
PostgreSQL 9.6.2 on x86_64-apple-darwin16.4.0, compiled by Apple LLVM version
8.0.0 (clang-800.0.42.1), 64-bit
(1 row)
{noformat}
> Mapping for Types.BIT: boolean or BitSet?
> -
>
> Key: CALCITE-1927
> URL: https://issues.apache.org/jira/browse/CALCITE-1927
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.13.0
>Reporter: Vladimir Sitnikov
> Labels: pgjdbc, postgresql
>
> Currently Avatica implements `Types.BIT` as `Boolean` (see
> https://github.com/apache/calcite-avatica/blob/4db1fb9c66db8ccebc9e96ce678154ec69c557f0/core/src/main/java/org/apache/calcite/avatica/AvaticaSite.java#L227-L230
> )
> Certain databases (e.g. PostgreSQL) have {{bit\(n)}} and {{varbit\(n)}} data
> types that are "bit strings" (see
> https://www.postgresql.org/docs/9.6/static/datatype-bit.html )
> If both used together, {{getObject}} just blows when trying to convert thing
> like {{'01101'}} to a boolean.
> I wonder what should be the behavior for {{Types.BIT}}.
> The original discussion is here: https://github.com/pgjdbc/pgjdbc/issues/908
> PS. I'm not using Avatica + PostgreSQL + varbit combo yet, however I just
> want to weight different implementation options, and make it simpler for
> different JDBC implementations to talk to each other.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1927) Mapping for Types.BIT: boolean or BitSet?
[
https://issues.apache.org/jira/browse/CALCITE-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114748#comment-16114748
]
Julian Hyde commented on CALCITE-1927:
--
bq. There's setObject as well, and it would be quite hard to set bit(3) via
byte[]
If you mean setting the value of a column of type {{bit(3)}}, then I think
that's straightforward: the driver should just take bits 0, 1 and 2 of
byte\[0\].
If you mean setting just the third bit, there's no way to do that via JDBC. You
have to set the whole value.
> Mapping for Types.BIT: boolean or BitSet?
> -
>
> Key: CALCITE-1927
> URL: https://issues.apache.org/jira/browse/CALCITE-1927
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.13.0
>Reporter: Vladimir Sitnikov
> Labels: pgjdbc, postgresql
>
> Currently Avatica implements `Types.BIT` as `Boolean` (see
> https://github.com/apache/calcite-avatica/blob/4db1fb9c66db8ccebc9e96ce678154ec69c557f0/core/src/main/java/org/apache/calcite/avatica/AvaticaSite.java#L227-L230
> )
> Certain databases (e.g. PostgreSQL) have {{bit\(n)}} and {{varbit\(n)}} data
> types that are "bit strings" (see
> https://www.postgresql.org/docs/9.6/static/datatype-bit.html )
> If both used together, {{getObject}} just blows when trying to convert thing
> like {{'01101'}} to a boolean.
> I wonder what should be the behavior for {{Types.BIT}}.
> The original discussion is here: https://github.com/pgjdbc/pgjdbc/issues/908
> PS. I'm not using Avatica + PostgreSQL + varbit combo yet, however I just
> want to weight different implementation options, and make it simpler for
> different JDBC implementations to talk to each other.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1927) Mapping for Types.BIT: boolean or BitSet?
[
https://issues.apache.org/jira/browse/CALCITE-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114687#comment-16114687
]
Vladimir Sitnikov commented on CALCITE-1927:
{quote}getBoolean should give a value if m <= 1, an error otherwise;
getInt should give a value if m <= 32, an error otherwise;
getLong should give a value if m <= 64, an error otherwise;{quote}
This sounds quite consistent.
{quote} getObject should return the same as getBytes;{quote}
There's {{setObject}} as well, and it would be quite hard to set {{bit(3)}} via
{{byte[]}}
> Mapping for Types.BIT: boolean or BitSet?
> -
>
> Key: CALCITE-1927
> URL: https://issues.apache.org/jira/browse/CALCITE-1927
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.13.0
>Reporter: Vladimir Sitnikov
> Labels: pgjdbc, postgresql
>
> Currently Avatica implements `Types.BIT` as `Boolean` (see
> https://github.com/apache/calcite-avatica/blob/4db1fb9c66db8ccebc9e96ce678154ec69c557f0/core/src/main/java/org/apache/calcite/avatica/AvaticaSite.java#L227-L230
> )
> Certain databases (e.g. PostgreSQL) have {{bit\(n)}} and {{varbit\(n)}} data
> types that are "bit strings" (see
> https://www.postgresql.org/docs/9.6/static/datatype-bit.html )
> If both used together, {{getObject}} just blows when trying to convert thing
> like {{'01101'}} to a boolean.
> I wonder what should be the behavior for {{Types.BIT}}.
> The original discussion is here: https://github.com/pgjdbc/pgjdbc/issues/908
> PS. I'm not using Avatica + PostgreSQL + varbit combo yet, however I just
> want to weight different implementation options, and make it simpler for
> different JDBC implementations to talk to each other.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1927) Mapping for Types.BIT: boolean or BitSet?
[
https://issues.apache.org/jira/browse/CALCITE-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114668#comment-16114668
]
Julian Hyde commented on CALCITE-1927:
--
So I guess some databases allow only {{BIT(1)}} and others allow {{BIT(m)}} for
{{m}} up to some database-dependent limit. Safest thing seems to be to transmit
the {{BIT(m)}} type as {{VARBINARY((m + 7) / 8)}}. Accessor methods should do
something sensible if possible:
* getBoolean should give a value if m <= 1, an error otherwise;
* getInt should give a value if m <= 32, an error otherwise;
* getLong should give a value if m <= 64, an error otherwise;
* similarly getShort, getByte;
* getBytes should give a value (padding with zero bits to fill up the last
byte);
* getString should return e.g. '101';
* getObject should return the same as getBytes;
* other methods always throw.
> Mapping for Types.BIT: boolean or BitSet?
> -
>
> Key: CALCITE-1927
> URL: https://issues.apache.org/jira/browse/CALCITE-1927
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.13.0
>Reporter: Vladimir Sitnikov
> Labels: pgjdbc, postgresql
>
> Currently Avatica implements `Types.BIT` as `Boolean` (see
> https://github.com/apache/calcite-avatica/blob/4db1fb9c66db8ccebc9e96ce678154ec69c557f0/core/src/main/java/org/apache/calcite/avatica/AvaticaSite.java#L227-L230
> )
> Certain databases (e.g. PostgreSQL) have {{bit\(n)}} and {{varbit\(n)}} data
> types that are "bit strings" (see
> https://www.postgresql.org/docs/9.6/static/datatype-bit.html )
> If both used together, {{getObject}} just blows when trying to convert thing
> like {{'01101'}} to a boolean.
> I wonder what should be the behavior for {{Types.BIT}}.
> The original discussion is here: https://github.com/pgjdbc/pgjdbc/issues/908
> PS. I'm not using Avatica + PostgreSQL + varbit combo yet, however I just
> want to weight different implementation options, and make it simpler for
> different JDBC implementations to talk to each other.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1927) Mapping for Types.BIT: boolean or BitSet?
[
https://issues.apache.org/jira/browse/CALCITE-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114633#comment-16114633
]
Julian Hyde commented on CALCITE-1927:
--
The BIT type is obsolete in the SQL standard, so I don't feel strongly about
this. Anyone using Avatica to access Calcite or Hbase (via Phoenix) will either
be using BOOLEAN, BINARY or VARBINARY. I can't imagine a case where people
would want, say, 11 bits but weren't prepared to use a data structure that gave
them 16.
Neither does Calcite support bit strings, e.g. {{b'101'}}.
In [SQL
Server|https://docs.microsoft.com/en-us/sql/t-sql/data-types/bit-transact-sql]
it seems to be limited to 1 bit (0, 1 or null), so it has the same information
content as BOOLEAN.
[MySQL|https://dev.mysql.com/doc/refman/5.7/en/bit-type.html] allows {{BIT(m)}}
with m up to 64. Each bit can have a value of 0 or 1.
> Mapping for Types.BIT: boolean or BitSet?
> -
>
> Key: CALCITE-1927
> URL: https://issues.apache.org/jira/browse/CALCITE-1927
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.13.0
>Reporter: Vladimir Sitnikov
> Labels: pgjdbc, postgresql
>
> Currently Avatica implements `Types.BIT` as `Boolean` (see
> https://github.com/apache/calcite-avatica/blob/4db1fb9c66db8ccebc9e96ce678154ec69c557f0/core/src/main/java/org/apache/calcite/avatica/AvaticaSite.java#L227-L230
> )
> Certain databases (e.g. PostgreSQL) have {{bit\(n)}} and {{varbit\(n)}} data
> types that are "bit strings" (see
> https://www.postgresql.org/docs/9.6/static/datatype-bit.html )
> If both used together, {{getObject}} just blows when trying to convert thing
> like {{'01101'}} to a boolean.
> I wonder what should be the behavior for {{Types.BIT}}.
> The original discussion is here: https://github.com/pgjdbc/pgjdbc/issues/908
> PS. I'm not using Avatica + PostgreSQL + varbit combo yet, however I just
> want to weight different implementation options, and make it simpler for
> different JDBC implementations to talk to each other.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1927) Mapping for Types.BIT: boolean or BitSet?
[
https://issues.apache.org/jira/browse/CALCITE-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-1927:
---
Description:
Currently Avatica implements `Types.BIT` as `Boolean` (see
https://github.com/apache/calcite-avatica/blob/4db1fb9c66db8ccebc9e96ce678154ec69c557f0/core/src/main/java/org/apache/calcite/avatica/AvaticaSite.java#L227-L230
)
Certain databases (e.g. PostgreSQL) have {{bit\(n)}} and {{varbit\(n)}} data
types that are "bit strings" (see
https://www.postgresql.org/docs/9.6/static/datatype-bit.html )
If both used together, {{getObject}} just blows when trying to convert thing
like {{'01101'}} to a boolean.
I wonder what should be the behavior for {{Types.BIT}}.
The original discussion is here: https://github.com/pgjdbc/pgjdbc/issues/908
PS. I'm not using Avatica + PostgreSQL + varbit combo yet, however I just want
to weight different implementation options, and make it simpler for different
JDBC implementations to talk to each other.
was:
Currently Avatica implements `Types.BIT` as `Boolean` (see
https://github.com/apache/calcite-avatica/blob/4db1fb9c66db8ccebc9e96ce678154ec69c557f0/core/src/main/java/org/apache/calcite/avatica/AvaticaSite.java#L227-L230
)
Certain databases (e.g. PostgreSQL) have bit(n) and varbit(n) data types that
are "bit strings" (see
https://www.postgresql.org/docs/9.6/static/datatype-bit.html )
If both used together, {{getObject}} just blows when trying to convert thing
like {{'01101'}} to a boolean.
I wonder what should be the behavior for {{Types.BIT}}.
The original discussion is here: https://github.com/pgjdbc/pgjdbc/issues/908
PS. I'm not using Avatica + PostgreSQL + varbit combo yet, however I just want
to weight different implementation options, and make it simpler for different
JDBC implementations to talk to each other.
> Mapping for Types.BIT: boolean or BitSet?
> -
>
> Key: CALCITE-1927
> URL: https://issues.apache.org/jira/browse/CALCITE-1927
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.13.0
>Reporter: Vladimir Sitnikov
> Labels: pgjdbc, postgresql
>
> Currently Avatica implements `Types.BIT` as `Boolean` (see
> https://github.com/apache/calcite-avatica/blob/4db1fb9c66db8ccebc9e96ce678154ec69c557f0/core/src/main/java/org/apache/calcite/avatica/AvaticaSite.java#L227-L230
> )
> Certain databases (e.g. PostgreSQL) have {{bit\(n)}} and {{varbit\(n)}} data
> types that are "bit strings" (see
> https://www.postgresql.org/docs/9.6/static/datatype-bit.html )
> If both used together, {{getObject}} just blows when trying to convert thing
> like {{'01101'}} to a boolean.
> I wonder what should be the behavior for {{Types.BIT}}.
> The original discussion is here: https://github.com/pgjdbc/pgjdbc/issues/908
> PS. I'm not using Avatica + PostgreSQL + varbit combo yet, however I just
> want to weight different implementation options, and make it simpler for
> different JDBC implementations to talk to each other.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-1927) Mapping for Types.BIT: boolean or BitSet?
Vladimir Sitnikov created CALCITE-1927:
--
Summary: Mapping for Types.BIT: boolean or BitSet?
Key: CALCITE-1927
URL: https://issues.apache.org/jira/browse/CALCITE-1927
Project: Calcite
Issue Type: Bug
Components: avatica
Affects Versions: 1.13.0
Reporter: Vladimir Sitnikov
Currently Avatica implements `Types.BIT` as `Boolean` (see
https://github.com/apache/calcite-avatica/blob/4db1fb9c66db8ccebc9e96ce678154ec69c557f0/core/src/main/java/org/apache/calcite/avatica/AvaticaSite.java#L227-L230
)
Certain databases (e.g. PostgreSQL) have bit(n) and varbit(n) data types that
are "bit strings" (see
https://www.postgresql.org/docs/9.6/static/datatype-bit.html )
If both used together, {{getObject}} just blows when trying to convert thing
like {{'01101'}} to a boolean.
I wonder what should be the behavior for {{Types.BIT}}.
The original discussion is here: https://github.com/pgjdbc/pgjdbc/issues/908
PS. I'm not using Avatica + PostgreSQL + varbit combo yet, however I just want
to weight different implementation options, and make it simpler for different
JDBC implementations to talk to each other.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1902) ResultSet.previous() throws UnsupportedOperationException, but should throw SQLFeatureNotSupportedException
[ https://issues.apache.org/jira/browse/CALCITE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114479#comment-16114479 ] Sergio Sainz commented on CALCITE-1902: --- Hey [~julianhyde], thanks for the review :) I used Helper.INSTANCE, because I thought statement could be null and hence drop null pointer exception when trying to call "unsupported" method. Do you think statement.helper is better? > ResultSet.previous() throws UnsupportedOperationException, but should throw > SQLFeatureNotSupportedException > --- > > Key: CALCITE-1902 > URL: https://issues.apache.org/jira/browse/CALCITE-1902 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: 1.10.0 >Reporter: Sergio Sainz >Assignee: Sergio Sainz >Priority: Minor > Fix For: avatica-1.11.0 > > > boolean java.sql.ResultSet.previous() throws SQLException should throw > SQLException, but it is throwing UnsupportedOperationException instead. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1926) Function names are unparsed quoted while PostgreSQL can only handle unquoted function names
Muhammad Gelbana created CALCITE-1926:
-
Summary: Function names are unparsed quoted while PostgreSQL can
only handle unquoted function names
Key: CALCITE-1926
URL: https://issues.apache.org/jira/browse/CALCITE-1926
Project: Calcite
Issue Type: Bug
Components: jdbc-adapter
Affects Versions: 1.13.0
Reporter: Muhammad Gelbana
Assignee: Julian Hyde
While working on a Drill plugin, Calcite unparsed a *JdbcRel* node and produced
the following PostgreSQL query
{code:sql}
SELECT "TEMP( Test)( 535799381)( 0)"
FROM (SELECT "STRPOS"("str1", 'BI') = 1 AS "TEMP( Test)( 535799381)( 0)"
FROM "TestV1"."Calcs") AS "t"
GROUP BY "TEMP( Test)( 535799381)( 0)"
{code}
The query fails due to a parsing exception, the reason is that the *STRPOS*
function name is quoted using double quotes. I tried the query manually without
quoting the function name and it executed successfully.
I debugged through Calcite and found that the [this
method|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlUtil.java#L262]
unparses the function name as a plain identifier which leads to the [quoting
of the function
name|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlIdentifier.java?deDup474625=1#L287]
if the dialect supports it.
Drill uses Calcite v1.4 but as I compared it with the master branch, I found
them identical.
I haven't tried that with custom functions yet.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1925) JaninoRelMetadataProvider to cache null value
[ https://issues.apache.org/jira/browse/CALCITE-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114118#comment-16114118 ] Ted Xu commented on CALCITE-1925: - Here https://github.com/apache/calcite/pull/507 is a rough showcase. I'll try if I can create a test. > JaninoRelMetadataProvider to cache null value > - > > Key: CALCITE-1925 > URL: https://issues.apache.org/jira/browse/CALCITE-1925 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.13.0 >Reporter: Ted Xu >Assignee: Julian Hyde > > JaninoRelMetadataProvider should cache null value to improve performance. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1925) JaninoRelMetadataProvider to cache null value
Ted Xu created CALCITE-1925: --- Summary: JaninoRelMetadataProvider to cache null value Key: CALCITE-1925 URL: https://issues.apache.org/jira/browse/CALCITE-1925 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.13.0 Reporter: Ted Xu Assignee: Julian Hyde JaninoRelMetadataProvider should cache null value to improve performance. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
