[reporter="angel", created="Fri, 17 Mar 2006 15:10:45 -0500 (GMT-05:00)"]
The output for the query values(multiset[1]) gives the multiset in binary
form. It is not understandable.
Possible solution is for sqlline to cast values to strings if it doesn't know
how to print them.
This is also a problem for the row parser functions, which returns a RecordType.
Only the first column of the resulting row is displayed for the following query:
0: jdbc:sqlstream:> select FIXED_COLUMN_LOG_PARSE('one two', 'a START 0 FOR 3,
b START 4') from (values(1));
+---------+
| EXPR$0 |
+---------+
| one |
+---------+
1 row selected (0.029 seconds)
Again, it is possible but inconvenient to work around the problem by doing the
following:
0: jdbc:sqlstream:> select t.r."a", t.r."b" from
. . . . . . . . . > (select FIXED_COLUMN_LOG_PARSE('one two', 'a START 0 FOR
3, b START 4') as r from (values(1))) as t;
+------+------+
| a | b |
+------+------+
| one | two |
+------+------+
------- Comment #1 From Julian Hyde 2005-06-19 22:23 [reply] -------
Your thoughts on this, John?
------- Comment #2 From John Sichi 2005-06-19 23:01 [reply] -------
Actually, sqlline always uses getString, so it doesn't need to change at all.
There are two separate problems here:
(1) We don't yet support java.sql.Array for fetching multisets via JDBC. Once
we do, we just need to provide a toString method and make sure getString calls it.
(2) Our support for returning instances of java.sql.Struct is spotty. There's a
TODO in RelStructuredTypeFlattener for handling ROW types (which is what Angel's
function returns). And there's another one to make sure that these don't get
mangled by Fennel. And in cases where we do manage to return a Struct, the
toString implementation works but needs to be reviewed for standards conformity.
I'm accepting because I need to fix #2. But #1 needs a separate bug (it's
actually a leftover task from the original multiset implementation plan).
[reporter="angel", created="Fri, 17 Mar 2006 15:10:45 -0500 (GMT-05:00)"] The output for the query values(multiset[1]) gives the multiset in binary
form. It is not understandable.
0: jdbc:farrago:> values(multiset[1]);
+-------------+
| EXPR$0 |
+-------------+
| 0001000000 |
+-------------+
To actually see what the values of the multiset is, can work around this by
using the unnest operator (the unnest operator may not always work).
0: jdbc:farrago:> select*from unnest(values(multiset[1]));
+---------+
| EXPR$0 |
+---------+
| 1 |
+---------+
Possible solution is for sqlline to cast values to strings if it doesn't know
how to print them.
This is also a problem for the row parser functions, which returns a RecordType.
Only the first column of the resulting row is displayed for the following query:
0: jdbc:sqlstream:> select FIXED_COLUMN_LOG_PARSE('one two', 'a START 0 FOR 3,
b START 4') from (values(1));
+---------+
| EXPR$0 |
+---------+
| one |
+---------+
1 row selected (0.029 seconds)
Again, it is possible but inconvenient to work around the problem by doing the
following:
0: jdbc:sqlstream:> select t.r."a", t.r."b" from
. . . . . . . . . > (select FIXED_COLUMN_LOG_PARSE('one two', 'a START 0 FOR
3, b START 4') as r from (values(1))) as t;
+------+------+
| a | b |
+------+------+
| one | two |
+------+------+
------- Comment #1 From Julian Hyde 2005-06-19 22:23 [reply] -------
Your thoughts on this, John?
------- Comment #2 From John Sichi 2005-06-19 23:01 [reply] -------
Actually, sqlline always uses getString, so it doesn't need to change at all.
There are two separate problems here:
(1) We don't yet support java.sql.Array for fetching multisets via JDBC. Once
we do, we just need to provide a toString method and make sure getString calls it.
(2) Our support for returning instances of java.sql.Struct is spotty. There's a
TODO in RelStructuredTypeFlattener for handling ROW types (which is what Angel's
function returns). And there's another one to make sure that these don't get
mangled by Fennel. And in cases where we do manage to return a Struct, the
toString implementation works but needs to be reviewed for standards conformity.
I'm accepting because I need to fix #2. But #1 needs a separate bug (it's
actually a leftover task from the original multiset implementation plan).