OpenText Analytics Database 26.2.x – Data types

Sql-Reference: Binary data types (BINARY and VARBINARY)

Mon, 01 Jan 0001 00:00:00 +0000

Store raw-byte data, such as IP addresses, up to 65000 bytes. The BINARY and BINARY VARYING (VARBINARY) data types are collectively referred to as binary string types and the values of binary string types are referred to as binary strings. A binary string is a sequence of octets or bytes.

BYTEA and RAW are synonyms for VARBINARY.

Syntax

BINARY ( length )
{ VARBINARY | BINARY VARYING | BYTEA | RAW } ( max-length )

Arguments

length, max-length: The length of the string or column width, in bytes (octets).

BINARY and VARBINARY data types

BINARY and VARBINARY data types have the following attributes:

BINARY: A fixed-width string of length bytes, where the number of bytes is declared as an optional specifier to the type. If length is omitted, the default is 1. Where necessary, values are right-extended to the full width of the column with the zero byte. For example:
```
=> SELECT TO_HEX('ab'::BINARY(4));
  to_hex
----------
 61620000
```
VARBINARY: A variable-width string up to a length of max-length bytes, where the maximum number of bytes is declared as an optional specifier to the type. The default is the default attribute size, which is 80, and the maximum length is 65000 bytes. VARBINARY values are not extended to the full width of the column. For example:
```
=> SELECT TO_HEX('ab'::VARBINARY(4));
 to_hex
--------
 6162
```

Input formats

You can use several formats when working with binary values. The hexadecimal format is generally the most straightforward and is emphasized in OpenText™ Analytics Database documentation.

Binary values can also be represented in octal format by prefixing the value with a backslash '\'.

Note

If you use vsql, you must use the escape character (\) when you insert another backslash on input; for example, input '\141' as '\\141'.

You can also input values represented by printable characters. For example, the hexadecimal value '0x61' can also be represented by the symbol a.

See Data load.

On input, strings are translated from:

Hexadecimal representation to a binary value using the function HEX_TO_BINARY.
Bitstring representation to a binary value using the function BITSTRING_TO_BINARY.

Both functions take a VARCHAR argument and return a VARBINARY value.

Output formats

Like the input format, the output format is a hybrid of octal codes and printable ASCII characters. A byte in the range of printable ASCII characters (the range [0x20, 0x7e]) is represented by the corresponding ASCII character, with the exception of the backslash ('\'), which is escaped as '\\'. All other byte values are represented by their corresponding octal values. For example, the bytes {97,92,98,99}, which in ASCII are {a,\,b,c}, are translated to text as 'a\\bc'.

Binary operators and functions

The binary operators &, ~, |, and # have special behavior for binary data types, as described in Bitwise operators.

The following aggregate functions are supported for binary data types:

BIT_AND, BIT_OR, and BIT_XOR are bit-wise operations that are applied to each non-null value in a group, while MAX and MIN are byte-wise comparisons of binary values.

Like their binary operator counterparts, if the values in a group vary in length, the aggregate functions treat the values as though they are all equal in length by extending shorter values with zero bytes to the full width of the column. For example, given a group containing the values 'ff', null, and 'f', a binary aggregate ignores the null value and treats the value 'f' as 'f0'. Also, like their binary operator counterparts, these aggregate functions operate on VARBINARY types explicitly and operate on BINARY types implicitly through casts. See Data type coercion operators (CAST).

Binary versus character data types

The BINARY and VARBINARY binary types are similar to the CHAR and VARCHAR character data types, respectively. They differ as follows:

Binary data types contain byte strings (a sequence of octets or bytes).
Character data types contain character strings (text).
The lengths of binary data types are measured in bytes, while character data types are measured in characters.

Examples

The following example shows HEX_TO_BINARY and TO_HEX usage.

Table t and its projection are created with binary columns:

=> CREATE TABLE t (c BINARY(1));
=> CREATE PROJECTION t_p (c) AS SELECT c FROM t;

Insert minimum byte and maximum byte values:

=> INSERT INTO t values(HEX_TO_BINARY('0x00'));
=> INSERT INTO t values(HEX_TO_BINARY('0xFF'));

Binary values can then be formatted in hex on output using the TO_HEX function:

=> SELECT TO_HEX(c) FROM t;
 to_hex
 --------
  00
  ff
 (2 rows)

The BIT_AND, BIT_OR, and BIT_XOR functions are interesting when operating on a group of values. For example, create a sample table and projections with binary columns:

The example that follows uses table t with a single column of VARBINARY data type:

=> CREATE TABLE t ( c VARBINARY(2) );
=> INSERT INTO t values(HEX_TO_BINARY('0xFF00'));
=> INSERT INTO t values(HEX_TO_BINARY('0xFFFF'));
=> INSERT INTO t values(HEX_TO_BINARY('0xF00F'));

Query table t to see column c output:

=> SELECT TO_HEX(c) FROM t;
 TO_HEX
--------
 ff00
 ffff
 f00f
(3 rows)

Now issue the bitwise AND operation. Because these are aggregate functions, an implicit GROUP BY operation is performed on results using (ff00&(ffff)&f00f):

=> SELECT TO_HEX(BIT_AND(c)) FROM t;
 TO_HEX
--------
f000
(1 row)

Issue the bitwise OR operation on (ff00|(ffff)|f00f):

=> SELECT TO_HEX(BIT_OR(c)) FROM t;
 TO_HEX
--------
ffff
(1 row)

Issue the bitwise XOR operation on (ff00#(ffff)#f00f):

=> SELECT TO_HEX(BIT_XOR(c)) FROM t;
 TO_HEX
--------
f0f0
(1 row)

Sql-Reference: Boolean data type

Mon, 01 Jan 0001 00:00:00 +0000

OpenText™ Analytics Database provides the standard SQL type BOOLEAN, which has two states: true and false. The third state in SQL boolean logic is unknown, which is represented by the NULL value.

Syntax

BOOLEAN

Parameters

Valid literal data values for input are:

`TRUE`	`'t'`	`'true'`	`'y'`	`'yes'`	`'1'`	`1`
`FALSE`	`'f'`	`'false'`	`'n'`	`'no'`	`'0'`	`0`

Notes

Do not confuse the BOOLEAN data type with Logical operators or the Boolean.
The keywords TRUE and FALSE are preferred and are SQL-compliant.
A Boolean value of NULL appears last (largest) in ascending order.
All other values must be enclosed in single quotes.
Boolean values are output using the letters t and f.

Sql-Reference: Character data types (CHAR and VARCHAR)

Mon, 01 Jan 0001 00:00:00 +0000

Stores strings of letters, numbers, and symbols. The CHARACTER (CHAR) and CHARACTER VARYING (VARCHAR) data types are collectively referred to as character string types, and the values of character string types are known as character strings.

Character data can be stored as fixed-length or variable-length strings. Fixed-length strings are right-extended with spaces on output; variable-length strings are not extended.

String literals in SQL statements must be enclosed in single quotes.

Syntax

{ CHAR | CHARACTER } [ (octet-length) ]
{ VARCHAR | CHARACTER VARYING ] } [ (octet-length) ]

Arguments

octet-length: Length of the string or column width, declared in bytes (octets).
This argument is optional.

CHAR versus VARCHAR data types

The following differences apply to CHAR and VARCHAR data:

CHAR is conceptually a fixed-length, blank-padded string. Trailing blanks (spaces) are removed on input and are restored on output. The default length is 1, and the maximum length is 65000 octets (bytes).
VARCHAR is a variable-length character data type. The default length is 80, and the maximum length is 65000 octets. For string values longer than 65000, use Long data types. Values can include trailing spaces.

Normally, you use VARCHAR for all of string data. Use CHAR when you need fixed-width string output. For example, you can use CHAR columns for data to be transferred to a legacy system that requires fixed-width strings.

Setting maximum length

When you define character columns, specify the maximum size of any string to be stored in a column. For example, to store strings up to 24 octets in length, use one of the following definitions:

CHAR(24)    --- fixed-length
VARCHAR(24) --- variable-length

The maximum length parameter for VARCHAR and CHAR data types refers to the number of octets that can be stored in that field, not the number of characters (Unicode code points). When using multibyte UTF-8 characters, the fields must be sized to accommodate from 1 to 4 octets per character, depending on the data. If the data loaded into a VARCHAR or CHAR column exceeds the specified maximum size for that column, data is truncated on UTF-8 character boundaries to fit within the specified size. See COPY.

Note

Remember to include the extra octets required for multibyte characters in the column-width declaration, keeping in mind the 65000 octet column-width limit.

Due to compression in OpenText™ Analytics Database, the cost of overestimating the length of these fields is incurred primarily at load time and during sorts.

NULL versus NUL

NULL and NUL differ as follows:

NUL represents a character whose ASCII/Unicode code is 0, sometimes qualified "ASCII NUL".
NULL means no value, and is true of a field (column) or constant, not of a character.

CHAR, LONG VARCHAR, and VARCHAR string data types accept ASCII NUL values.

In ascending sorts, NULL appears last (largest).

For additional information about NULL ordering, see NULL sort order.

The following example casts the input string containing NUL values to VARCHAR:

=> SELECT 'vert\0ica'::CHARACTER VARYING AS VARCHAR;
 VARCHAR
---------
 vert\0ica
(1 row)

The result contains 9 characters:

=> SELECT LENGTH('vert\0ica'::CHARACTER VARYING);
 length
--------
      9
(1 row)

If you use an extended string literal, the length is 8 characters:

=> SELECT E'vert\0ica'::CHARACTER VARYING AS VARCHAR;
 VARCHAR
---------
 vertica
(1 row)
=> SELECT LENGTH(E'vert\0ica'::CHARACTER VARYING);
 LENGTH
--------
      8
(1 row)

Sql-Reference: Date/time data types

Mon, 01 Jan 0001 00:00:00 +0000

OpenText™ Analytics Database supports the full set of SQL date and time data types.

The following rules apply to all date/time data types:

All have a size of 8 bytes.
A date/time value of NULL is smallest relative to all other date/time values,.
The database uses Julian dates for all date/time calculations, which can correctly predict and calculate any date more recent than 4713 BC to far into the future, based on the assumption that the average length of the year is 365.2425 days.
All the date/time data types accept the special literal value NOW to specify the current date and time. For example:
```
=> SELECT TIMESTAMP 'NOW';
         ?column?
---------------------------
 2020-09-23 08:23:50.42325
(1 row)
```
By default, the database rounds with a maximum precision of six decimal places. You can substitute an integer between 0 and 6 for p to specify your preferred level of precision.

The following table lists specific attributes of date/time data types:

Name	Description	Low Value	High Value	Resolution
`DATE`	Dates only (no time of day)	`~ 25e+15 BC`	`~ 25e+15 AD`	1 day
`TIME [(p)]`	Time of day only (no date)	`00:00:00.00`	`23:59:60.999999`	1 μs
`TIMETZ [(p)]`	Time of day only, with time zone	`00:00:00.00+14`	`23:59:59.999999-14`	1 μs
`TIMESTAMP [(p)]`	Both date and time, without time zone	`290279-12-22 19:59:05.224194 BC`	`294277-01-09 04:00:54.775806 AD`	1 μs
`TIMESTAMPTZ [(p)]*`	Both date and time, with time zone	`290279-12-22 19:59:05.224194 BC UTC`	`294277-01-09 04:00:54.775806 AD UTC`	1 μs
`INTERVAL DAY TO SECOND [(p)]`	Time intervals	`-106751991 days 04:00:54.775807`	`+-106751991 days 04:00:54.775807`	1 μs
`INTERVAL YEAR TO MONTH`	Time intervals	`~ -768e15 yrs`	`~ 768e15 yrs`	1 month

Time zone abbreviations for input

The database recognizes the files in /opt/vertica/share/timezonesets as date/time input values and defines the default list of strings accepted in the AT TIME ZONE zone parameter. The names are not necessarily used for date/time output—output is driven by the official time zone abbreviations associated with the currently selected time zone parameter setting.

Sql-Reference: Long data types

Mon, 01 Jan 0001 00:00:00 +0000

Store data up to 32000000 octets. OpenText™ Analytics Database supports two long data types:

LONG VARBINARY: Variable-length raw-byte data, such as spatial data. LONG VARBINARY values are not extended to the full width of the column.
LONG VARCHAR: Variable-length strings, such as log files and unstructured data. LONG VARCHAR values are not extended to the full width of the column.

Use LONG data types only when you need to store data greater than the maximum size of VARBINARY and VARCHAR data types (65 KB). Long data can include unstructured data, online comments or posts, or small log files.

Flex tables have a default LONG VARBINARY __raw__ column, with a NOT NULL constraint. For more information, see Flex tables.

Syntax

LONG VARBINARY [(max-length)]
LONG VARCHAR [(octet-length)]

Parameters

max-length: Length of the byte string or column width, declared in bytes (octets), up to 32000000.
Default: 1 MB
octet-length: Length of the string or column width, declared in bytes (octets), up to 32000000.
Default: 1 MB

Optimized performance

For optimal performance of LONG data types, OpenText recommends that you:

Use the LONG data types as storage only containers; the database supports operations on the content of LONG data types, but does not support all the operations that VARCHAR and VARBINARY take.
Use VARBINARY and VARCHAR data types, instead of their LONG counterparts, whenever possible. VARBINARY and VARCHAR data types are more flexible and have a wider range of operations.
Do not sort, segment, or partition projections on LONG data type columns.
Do not add constraints, such as a primary key, to any LONG VARBINARY or LONG VARCHAR columns.
Do not join or aggregate any LONG data type columns.

Examples

The following example creates a table user_comments with a LONG VARCHAR column and inserts data into it:

=> CREATE TABLE user_comments
                  (id INTEGER,
                  username VARCHAR(200),
                  time_posted TIMESTAMP,
                  comment_text LONG VARCHAR(200000));
=> INSERT INTO user_comments VALUES
                  (1,
                  'User1',
                  TIMESTAMP '2013-06-25 12:47:32.62',
                  'The weather tomorrow will be cold and rainy and then
                  on the day after, the sun will come and the temperature
                  will rise dramatically.');

Sql-Reference: Numeric data types

Mon, 01 Jan 0001 00:00:00 +0000

Numeric data types are numbers stored in database columns. These data types are typically grouped by:

Exact numeric types, values where the precision and scale need to be preserved. The exact numeric types are INTEGER, BIGINT, DECIMAL, NUMERIC, NUMBER, and MONEY.
Approximate numeric types, values where the precision needs to be preserved and the scale can be floating. The approximate numeric types are DOUBLE PRECISION, FLOAT, and REAL.

Implicit casts from INTEGER, FLOAT, and NUMERIC to VARCHAR are not supported. If you need that functionality, write an explicit cast using one of the following forms:

CAST(numeric-expression AS data-type)
numeric-expression::data-type

For example, you can cast a float to an integer as follows:

=> SELECT(FLOAT '123.5')::INT;
 ?column?
----------
      124
(1 row)

String-to-numeric data type conversions accept formats of quoted constants for scientific notation, binary scaling, hexadecimal, and combinations of numeric-type literals:

Scientific notation:

=> SELECT FLOAT '1e10';
  ?column?
-------------
 10000000000
(1 row)

BINARY scaling:

=> SELECT NUMERIC '1p10';
 ?column?
----------
     1024
(1 row)

hexadecimal:

=> SELECT NUMERIC '0x0abc';
 ?column?
----------
     2748
(1 row)

Sql-Reference: Spatial data types

Mon, 01 Jan 0001 00:00:00 +0000

OpenText™ Analytics Database supports two spatial data types. These data types store two- and three-dimensional spatial objects in a table column:

GEOMETRY: Spatial object with coordinates expressed as (x,y) pairs, defined in the Cartesian plane. All calculations use Cartesian coordinates.
GEOGRAPHY: Spatial object defined as on the surface of a perfect sphere, or a spatial object in the WGS84 coordinate system. Coordinates are expressed in longitude/latitude angular values, measured in degrees. All calculations are in meters. For perfect sphere calculations, the sphere has a radius of 6371 kilometers, which approximates the shape of the earth.

Note
Some spatial programs use an ellipsoid to model the earth, resulting in slightly different data.

The maximum size of a GEOMETRY or GEOGRAPHY data type is 10,000,000 bytes (10 MB). You cannot use either data type as a table's primary key.

Syntax

GEOMETRY [ (length) ]
GEOGRAPHY [ (length) ]

Parameters

length: The maximum amount of spatial data that a GEOMETRY or GEOGRAPHY column can store, up to 10 MB.
Default: 1 MB

Sql-Reference: UUID data type

Mon, 01 Jan 0001 00:00:00 +0000

Stores universally unique identifiers (UUIDs). UUIDs are 16-byte (128-bit) numbers used to uniquely identify records. To generate UUIDs, OpenText™ Analytics Database provides the function UUID_GENERATE, which returns UUIDs based on high-quality randomness from /dev/urandom.

Syntax

UUID

UUID input and output formats

UUIDs support input of case-insensitive string literal formats, as specified by RFC 4122. In general, a UUID is written as a sequence of hexadecimal digits, in several groups optionally separated by hyphens, for a total of 32 digits representing 128 bits.

The following input formats are valid:

6bbf0744-74b4-46b9-bb05-53905d4538e7
{6bbf0744-74b4-46b9-bb05-53905d4538e7}
6BBF074474B446B9BB0553905D4538E7
6BBf-0744-74B4-46B9-BB05-5390-5D45-38E7

On output, the database uses the following format:

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

For example, the following table defines column cust_id as a UUID:

=> CREATE TABLE public.Customers
(
    cust_id uuid,
    lname varchar(36),
    fname varchar(24)
);

The following input for cust_id uses several valid formats:

=>  COPY Customers FROM STDIN;
Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
>> {cede66b7-3d29-4da6-b700-871fc0ac57be}|Kearney|Thomas
>> 34462732ed5649838f3be735b0c32d50|Pham|Duc
>> 9fb0-1de0-1d63-4d09-9415-90e0-b4e9-3b9a|Steinberg|Jeremy
>> \.

On querying this table, the database formats all cust_id data in the same way:

=> SELECT cust_id, fname, lname FROM Customers;
                cust_id                | fname  |   lname
--------------------------------------+--------+-----------
 9fb01de0-1d63-4d09-9415-90e0b4e93b9a | Jeremy | Steinberg
 34462732-ed56-4983-8f3b-e735b0c32d50 | Duc    | Pham
 cede66b7-3d29-4da6-b700-871fc0ac57be | Thomas | Kearney
(3 rows)

Generating UUIDs

You can use the database function UUID_GENERATE to automatically generate UUIDs that uniquely identify table records. For example:

=> INSERT INTO Customers SELECT UUID_GENERATE(),'Rostova','Natasha';
 OUTPUT
--------
      1
(1 row)

=> COMMIT;
COMMIT
=> SELECT cust_id, fname, lname FROM Customers;
               cust_id                |  fname  |   lname
--------------------------------------+---------+-----------
 9fb01de0-1d63-4d09-9415-90e0b4e93b9a | Jeremy  | Steinberg
 34462732-ed56-4983-8f3b-e735b0c32d50 | Duc     | Pham
 cede66b7-3d29-4da6-b700-871fc0ac57be | Thomas  | Kearney
 9aad6757-fe1b-473a-a109-b89b7b358c69 | Natasha | Rostova
(4 rows)

NULL input and output

The following string is reserved as NULL for UUID columns:

00000000-0000-0000-0000-000000000000

The database always renders NULL as blank.

The following COPY statements insert NULL values into the UUID column, explicitly and implicitly:

=>  COPY Customers FROM STDIN NULL AS 'null';
Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
>> null|Doe|Jane
>> 00000000-0000-0000-0000-000000000000|Man|Nowhere
>> \.
=>  COPY Customers FROM STDIN;
>> |Doe|John
>> \.

In all cases, the database renders NULL as blank:

=> SELECT cust_id, fname, lname FROM Customers WHERE cust_id IS NULL;
 cust_id |  fname  | lname
---------+---------+-------
         | Nowhere | Man
         | Jane    | Doe
         | John    | Doe
(3 rows)

Usage restrictions

UUID data types only support relational operators and functions that are also supported by CHAR and VARCHAR data types—for example, MIN, MAX, and COUNT. UUID data types do not support mathematical operators or functions, such as SUM and AVG.

Sql-Reference: Data type coercion

Mon, 01 Jan 0001 00:00:00 +0000

OpenText™ Analytics Database supports two types of data type casting:

Implicit casting: The expression automatically converts the data from one type to another.
Explicit casting: A SQL statement specifies the target data type for the conversion.

Implicit casting

The ANSI SQL-92 standard supports implicit casting among similar data types:

Number types
CHAR, VARCHAR, LONG VARCHAR
BINARY, VARBINARY, LONG VARBINARY

The database supports two types of nonstandard implicit casts of scalar types:

From CHAR to FLOAT, to match the one from VARCHAR to FLOAT. The following example converts the CHAR '3' to a FLOAT so it can add the number 4.33 to the FLOAT result of the second expression:
```
=> SELECT '3'::CHAR + 4.33::FLOAT;
 ?column?
----------
   7.33
(1 row)
```
Between DATE and TIMESTAMP. The following example DATE to a TIMESTAMP and calculates the time 6 hours, 6 minutes, and 6 seconds back from 12:00 AM:
```
=> SELECT DATE('now') - INTERVAL '6:6:6';
      ?column?
---------------------
 2013-07-30 17:53:54
(1 row)
```

When there is no ambiguity about the data type of an expression value, it is implicitly coerced to match the expected data type. In the following statement, the quoted string constant '2' is implicitly coerced into an INTEGER value so that it can be the operand of an arithmetic operator (addition):

=> SELECT 2 + '2';
 ?column?
----------
        4
(1 row)

A concatenate operation explicitly takes arguments of any data type. In the following example, the concatenate operation implicitly coerces the arithmetic expression 2 + 2 and the INTEGER constant 2 to VARCHAR values so that they can be concatenated.

=> SELECT 2 + 2 || 2;
 ?column?
----------
 42
(1 row)

Another example is to first get today's date:

=> SELECT DATE 'now';
  ?column?
------------
 2013-07-31
(1 row)

The following command converts DATE to a TIMESTAMP and adds a day and a half to the results by using INTERVAL:

=> SELECT DATE 'now' + INTERVAL '1 12:00:00';
      ?column?
---------------------
 2013-07-31 12:00:00
(1 row)

Most implicit casts stay within their relational family and go in one direction, from less detailed to more detailed. For example:

DATE to TIMESTAMP/TZ
INTEGER to NUMERIC to FLOAT
CHAR to FLOAT
CHAR to VARCHAR
CHAR and/or VARCHAR to FLOAT
CHAR to LONG VARCHAR
VARCHAR to LONG VARCHAR
BINARY to VARBINARY
BINARY to LONG VARBINARY
VARBINARY to LONG VARBINARY

More specifically, data type coercion works in this manner:

Conversion	Notes
INT8 > FLOAT8	Implicit, can lose significance
FLOAT8 > INT8	Explicit, rounds
VARCHAR <-> CHAR	Implicit, adjusts trailing spaces
VARBINARY <-> BINARY	Implicit, adjusts trailing NULs
VARCHAR > LONG VARCHAR	Implicit, adjusts trailing spaces
VARBINARY > LONG VARBINARY	Implicit, adjusts trailing NULs

No other types cast to or from LONGVARBINARY, VARBINARY, or BINARY. In the following list, <any> means one these types: INT8, FLOAT8, DATE, TIME, TIMETZ, TIMESTAMP, TIMESTAMPTZ, INTERVAL:

<any> -> VARCHAR—implicit
VARCHAR -> <any>—explicit, except that VARCHAR->FLOAT is implicit
<any> <-> CHAR—explicit
DATE -> TIMESTAMP/TZ—implicit
TIMESTAMP/TZ -> DATE—explicit, loses time-of-day
TIME -> TIMETZ—implicit, adds local timezone
TIMETZ -> TIME—explicit, loses timezone
TIME -> INTERVAL—implicit, day to second with days=0
INTERVAL -> TIME—explicit, truncates non-time parts
TIMESTAMP <-> TIMESTAMPTZ—implicit, adjusts to local timezone
TIMESTAMP/TZ -> TIME—explicit, truncates non-time parts
TIMESTAMPTZ -> TIMETZ—explicit
VARBINARY -> LONG VARBINARY—implicit
LONG VARBINARY -> VARBINARY—explicit
VARCHAR -> LONG VARCHAR—implicit
LONG VARCHAR -> VARCHAR—explicit
Important

Implicit casts from INTEGER, FLOAT, and NUMERIC to VARCHAR are not supported. If you need that functionality, write an explicit cast:
```
CAST(x AS data-type-name)
```
or
```
x::data-type-name
```
The following example casts a FLOAT to an INTEGER:
```
=> SELECT(FLOAT '123.5')::INT;
 ?column?
----------
      124
(1 row)
```

String-to-numeric data type conversions accept formats of quoted constants for scientific notation, binary scaling, hexadecimal, and combinations of numeric-type literals:

Scientific notation:

=> SELECT FLOAT '1e10';
  ?column?
-------------
 10000000000
(1 row)

BINARY scaling:

=> SELECT NUMERIC '1p10';
 ?column?
----------
     1024
(1 row)

hexadecimal:

=> SELECT NUMERIC '0x0abc';
 ?column?
----------
     2748
(1 row)

Complex types

Collections (arrays and sets) can be cast implicitly and explicitly. Casting a collection casts each element of the collection. You can, for example, cast an ARRAY[VARCHAR] to an ARRAY[INT] or a SET[DATE] to SET[TIMESTAMPTZ]. You can cast between arrays and sets.

When casting to a bounded native array, inputs that are too long are truncated. When casting to a non-native array (an array containing complex data types including other arrays), if the new bounds are too small for the data the cast fails

Rows (structs) can be cast implicitly and explicitly. Casting a ROW casts each field value. You can specify new field names in the cast or specify only the field types to use the existing field names.

Casting can increase the storage needed for a column. For example, if you cast an array of INT to an array of VARCHAR(50), each element takes more space and thus the array takes more space. If the difference is extreme or the array has many elements, this could mean that the array no longer fits within the space allotted for the column. In this case the operation reports an error and fails.

Examples

The following example casts three strings as NUMERICs:

=> SELECT NUMERIC '12.3e3', '12.3p10'::NUMERIC, CAST('0x12.3p-10e3' AS NUMERIC);
 ?column? | ?column? |     ?column?
----------+----------+-------------------
    12300 |  12595.2 | 17.76123046875000
(1 row)

This example casts a VARBINARY string into a LONG VARBINARY data type:

=> SELECT B'101111000'::LONG VARBINARY;
 ?column?
----------
 \001x
(1 row)

The following example concatenates a CHAR with a LONG VARCHAR, resulting in a LONG VARCHAR:

=> \set s ''''`cat longfile.txt`''''
=> SELECT length ('a' || :s ::LONG VARCHAR);
 length
----------
 65002
(1 row)

The following example casts a combination of NUMERIC and INTEGER data into a NUMERIC result:

=> SELECT (18. + 3./16)/1024*1000;
                ?column?
-----------------------------------------
 17.761230468750000000000000000000000000
(1 row)

Note

In SQL expressions, pure numbers between (–2^63–1) and (2^63–1) are INTEGERs. Numbers with decimal points are NUMERIC.

Sql-Reference: Data type coercion chart

Mon, 01 Jan 0001 00:00:00 +0000

Conversion types

The following table defines all possible type conversions that OpenText™ Analytics Database supports. The data types in the first column of the table are the inputs to convert, and the remaining columns indicate the result for the different conversion types.

Source Data Type	Implicit	Explicit	Assignment	Assignment without numeric meaning	Conversion without explicit casting
BOOLEAN			INTEGER, LONG VARCHAR, VARCHAR, CHAR
INTEGER	BOOLEAN, NUMERIC, FLOAT		INTERVAL DAY/SECOND, INTERVAL YEAR/MONTH	LONG VARCHAR, VARCHAR, CHAR
NUMERIC	FLOAT		INTEGER	LONG VARCHAR, VARCHAR, CHAR	NUMERIC
FLOAT			INTEGER, NUMERIC	LONG VARCHAR, VARCHAR, CHAR
LONG VARCHAR	FLOAT, CHAR	BOOLEAN, INTEGER, NUMERIC, VARCHAR, TIMESTAMP, TIMESTAMPTZ, DATE, TIME, TIMETZ, INTERVAL DAY/SECOND, INTERVAL YEAR/MONTH, LONG VARBINARY			`LONG VARCHAR`
VARCHAR	CHAR, FLOAT, LONG VARCHAR	BOOLEAN, INTEGER, NUMERIC, TIMESTAMP, TIMESTAMPTZ, DATE, TIME, TIMETZ, UUID, BINARY, VARBINARY, INTERVAL DAY/SECOND, INTERVAL YEAR/MONTH			VARCHAR
CHAR	FLOAT, LONG VARCHAR, VARCHAR	BOOLEAN, INTEGER, NUMERIC, TIMESTAMP, TIMESTAMPTZ, DATE, TIME, TIMETZ, UUID (CHAR length ≥ 36), BINARY, VARBINARY, INTERVAL DAY/SECOND, INTERVAL YEAR/MONTH			CHAR
TIMESTAMP	TIMESTAMPTZ		LONG CHAR, VARCHAR, CHAR, DATE, TIME		TIMESTAMP
TIMESTAMPTZ	TIMESTAMP		LONG CHAR, VARCHAR, CHAR, DATE, TIME, TIMETZ		TIMESTAMPTZ
DATE	TIMESTAMP		LONG CHAR, VARCHAR, CHAR, TIMESTAMPTZ
TIME	TIMETZ	TIMESTAMP, TIMESTAMPTZ, INTERVAL DAY/SECOND	LONG CHAR, VARCHAR, CHAR		TIME
TIMETZ		TIMESTAMP, TIMESTAMPTZ	LONG CHAR, VARCHAR, CHAR, TIME		TIMETZ
INTERVAL DAY/SECOND		TIME	INTEGER, LONG CHAR, VARCHAR, CHAR		INTERVAL DAY/SECOND
INTERVAL YEAR/MONTH			INTEGER, LONG CHAR, VARCHAR, CHAR		INTERVAL YEAR/MONTH
LONG VARBINARY		VARBINARY			LONG VARBINARY
VARBINARY	LONG VARBINARY, BINARY				VARBINARY
BINARY	VARBINARY				BINARY
UUID		CHAR(36), VARCHAR			UUID

Implicit and explicit conversion

OpenText™ Analytics Database supports data type conversion of values without explicit casting, such as NUMERIC(10,6) -> NUMERIC(18,4).Implicit data type conversion occurs automatically when converting values of different, but compatible, types to the target column's data type. For example, when adding values, (INTEGER + NUMERIC), the result is implicitly cast to a NUMERIC type to accommodate the prominent type in the statement. Depending on the input data types, different precision and scale can occur.

An explicit type conversion must occur when the source data cannot be cast implicitly to the target column's data type.

Assignment conversion

In data assignment conversion, coercion implicitly occurs when values are assigned to database columns in an INSERT or UPDATE...SET statement. For example, in a statement that includes INSERT...VALUES('2.5'), where the target column data type is NUMERIC(18,5), a cast from VARCHAR to the column data type is inferred.

In an assignment without numeric meaning, the value is subject to CHAR/VARCHAR/LONG VARCHAR comparisons.

Sql-Reference: Complex types

Mon, 01 Jan 0001 00:00:00 +0000

Complex types such as structures (also known as rows), arrays, and maps are composed of primitive types and sometimes other complex types. Complex types can be used in the following ways:

Arrays and rows (in any combination) can be used as column data types in both native and external tables.
Sets of primitive element types can be used as column data types in native and external tables.
Arrays and rows, but not combinations of them, can be created as literals, for example to use in query expressions.

The MAP type is a legacy type. To represent maps, use ARRAY[ROW].

If a flex table has a real column that uses a complex type, the values from that column are not included in the __raw__ column. For more information, see Loading Data into Flex Table Real Columns.

Sql-Reference: Data type mappings between OpenText Analytics Database and Oracle

Mon, 01 Jan 0001 00:00:00 +0000

Oracle uses proprietary data types for all main data types, such as VARCHAR, INTEGER, FLOAT, DATE. Before migrating a database from Oracle to OpenText™ Analytics Database, first convert the schema to minimize errors and time spent fixing erroneous data issues.

The following table compares the behavior of Oracle data types to OpenText™ Analytics Database data types.

Oracle	OpenText™ Analytics Database	Notes
NUMBER (no explicit precision)	INTEGER	In Oracle, the NUMBER data type with no explicit precision stores each number N as an integer M, together with a scale S. The scale can range from -84 to 127, while the precision of M is limited to 38 digits. Thus: N = M * 10^{^}S When precision is specified, precision/scale applies to all entries in the column. If omitted, the scale defaults to 0. For the common case—Oracle NUMBER with no explicit precision used to store only integer values—the database INTEGER data type is the most appropriate and the fastest equivalent data type. However, INTEGER is limited to a little less than 19 digits, with a scale of 0: `[-9223372036854775807, +9223372036854775807]`.
NUMERIC	If an Oracle column contains integer values outside of the range `[-9223372036854775807, +9223372036854775807]`, then use the database data type NUMERIC(p,0) where p is the maximum number of digits required to represent values of the source data. If the data is exact with fractional places—such as dollars, OpenText recommends that you use NUMERIC(p,s) where p is the precision (total number of digits) and s is the maximum scale (number of decimal places). The database conforms to standard SQL, which requires that p ≥ s and s ≥ 0. The NUMERIC data type is most effective for p=18 and increasingly expensive for p=37, 58, 67, etc., where p ≤ 1024. Tip OpenText recommends against using the data type NUMERIC(38,s) as a default "failsafe" mapping to ensure no loss of precision. NUMERIC(18,s) is better and INTEGER or FLOAT are even better options, if one of these data types are suitable for the task.
FLOAT	Even though no explicit scale is specified for an Oracle NUMBER column, Oracle allows non-integer values, each with its own scale. If the data stored in the column is approximate, OpenText recommends that you use the FLOAT data type, which is standard IEEE floating point, like ORACLE BINARY_DOUBLE.
NUMBER(P,0) P ≤ 18	INTEGER	For Oracle NUMBER data types with 0 scale and a precision less than or equal to 18, use the OpenText™ Analytics Database INTEGER data type.
NUMBER(P,0) P > 18	NUMERIC(p,0)	In the rare case where a Oracle column specifies precision greater than 18, use the OpenText™ Analytics Database data type NUMERIC(p, 0), where p = P.
NUMBER(P,S) All cases other than above	NUMERIC(p,s)	When P ≥ S and S ≥ 0, use p = P and s = S, unless the data allows reducing P or using FLOAT as discussed above. If S > P, use p = S, s = S. If S < 0, use p = P – S, s = 0.
FLOAT
NUMERIC(P,S)		Rarely used in Oracle, see notes for Oracle NUMBER.
DECIMAL(P,S)		Synonym for Oracle NUMERIC.
BINARY_FLOAT	FLOAT	Same as FLOAT(53) or DOUBLE PRECISION
BINARY_DOUBLE	FLOAT	Same as FLOAT(53) or DOUBLE PRECISION
RAW	VARBINARY	Maximum sizes compared: Oracle RAW data type: 2000 bytes OpenText™ Analytics Database VARBINARY: 65000 bytes
LONG RAW	LONG VARBINARY	Maximum sizes compared: Oracle’s LONG RAW is 2GB OpenText™ Analytics Database LONG VARBINARY is 32M bytes/octets (~30MB) Caution Be careful to avoid truncation when migrating Oracle LONG RAW data to OpenText™ Analytics Database.
CHAR(n)	CHAR(n)	Maximum sizes compared: Oracle CHAR: 2000 bytes OpenText™ Analytics Database CHAR : 65000 bytes
NCHAR(n)	CHAR(n*3)	OpenText™ Analytics Database supports national characters with CHAR(n) as variable-length UTF8-encoded UNICODE character string. UTF-8 represents ASCII in 1 byte, most European characters in 2 bytes, and most oriental and Middle Eastern characters in 3 bytes.
VARCHAR2(n)	VARCHAR(n)	Maximum sizes compared: Oracle VARCHAR2: 4000 bytes OpenText™ Analytics Database VARCHAR: 65000 bytes Important The Oracle VARCHAR2 and OpenText™ Analytics Database VARCHAR data types are semantically different: VARCHAR exhibits standard SQL behavior VARCHAR2 is inconsistent with standard SQL behavior in that it treats an empty string as NULL value, and uses non-padded comparison if one operand is VARCHAR2.
NVARCHAR2(n)	VARCHAR(n*3)	See notes for NCHAR.
DATE	TIMESTAMP	Oracle’s DATE is different from the SQL standard DATE data type implemented by OpenText™ Analytics Database. Oracle’s DATE includes the time (no fractional seconds), while OpenText™ Analytics Database DATE data types include only date as per the SQL standard.
DATE
TIMESTAMP	TIMESTAMP	TIMESTAMP defaults to six places—that is, to microseconds.
TIMESTAMP WITH TIME ZONE	TIMESTAMP WITH TIME ZONE	TIME ZONE defaults to the currently SET or system time zone.
INTERVAL YEAR TO MONTH	INTERVAL YEAR TO MONTH	As per the SQL standard, you can qualify OpenText™ Analytics Database INTERVAL data types with the YEAR TO MONTH subtype.
INTERVAL DAY TO SECOND	INTERVAL DAY TO SECOND	The default subtype for OpenText™ Analytics Database INTERVAL data types is DAY TO SECOND.
CLOB	LONG VARCHAR	You can store a CLOB (character large object) or BLOB (binary large object) value in a table or in an external location. The maximum size of a CLOB or BLOB is 128 TB. You can store OpenText™ Analytics Database LONG data types only in LONG VARCHAR and LONG VARBINARY columns. The maximum size of LONG data types is 32M bytes.
BLOB	LONG VARBINARY
LONG	LONG VARCHAR	Oracle recommends using CLOB and BLOB data types instead of LONG and LONG RAW data types. An Oracle table can contain only one LONG column, The maximum size of a LONG or LONG RAW data type is 2 GB.
LONG RAW	LONG VARBINARY

OpenText Analytics Database 26.2.x – Data types

Sql-Reference: Binary data types (BINARY and VARBINARY)

Syntax

Arguments

BINARY and VARBINARY data types

Input formats

Note

Output formats

Binary operators and functions

Binary versus character data types

Examples

Sql-Reference: Boolean data type

Syntax

Parameters

Notes

See also

Sql-Reference: Character data types (CHAR and VARCHAR)

Syntax

Arguments

CHAR versus VARCHAR data types

Setting maximum length

Note

NULL versus NUL

Sql-Reference: Date/time data types

Time zone abbreviations for input

Sql-Reference: Long data types

Syntax

Parameters

Optimized performance

Examples

Sql-Reference: Numeric data types

Sql-Reference: Spatial data types

Note

Syntax

Parameters

Sql-Reference: UUID data type

Syntax

UUID input and output formats

Generating UUIDs

NULL input and output

Usage restrictions

Sql-Reference: Data type coercion

Implicit casting

Important

Complex types

Examples

Note

See also

Sql-Reference: Data type coercion chart

Conversion types

Implicit and explicit conversion

Assignment conversion

See also

Sql-Reference: Complex types

Sql-Reference: Data type mappings between OpenText Analytics Database and Oracle

Tip

Caution

Important