[
https://issues.jboss.org/browse/TEIID-1834?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIID-1834:
---------------------------------------
Added the varbinary type logic. The runtime type is a byte[] wrapper called BinaryType.
Our batches and any values passed to translators will have binary values wrapped with a
BinaryType. However UDF functions will just use a type signature of byte[] (or object).
We are also taking ownership of built-in type metadata. For now the first step was to
remove unused information and to move the datatype info out of the System.vdb datatypes
index and into a types.dat sv file in the metadata project. The only modification was
adding the varbinary type. We'll need further work to correct/consolidate/refine type
info.
Add support for a comparable binary type
----------------------------------------
Key: TEIID-1834
URL:
https://issues.jboss.org/browse/TEIID-1834
Project: Teiid
Issue Type: Feature Request
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.0
Attachments: varbinary.patch
Teiid currently lacks a binary/varbinary type. Since we have both blob/clob, it would be
natural to also introduce a varbinary analog to string. It would be a comparable type and
need an escape syntax for entering literals. Translators would need to be modified to
account for binary literals.
See the forum post for current workarounds. We also as a one off have previously allowed
clob types to be comparable, see also TEIID-1248. Another approach would by to allow
clob/blob to comparable in Teiid, but possibly not at the source as per the searchability
metadata. We would still need to support an escape syntax and modify translators to use
native type information and the appropriate literal format. The advantage of this latter
approach is that there is nothing more that designer must do to support this case. The
most practical benefit from introducing a varbinary type would be in having a better size
estimate (it would be limited to 8000 bytes) for buffering.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira