Data Type Details

Numeric data types

Exasol supports approximate and exact numerical data types. The difference when using the approximate data types arises from the possible rounding differences, which can occur due to the type of storage and the way computations are performed. Information losses of this nature do not occur when using exact numeric types because of storage type.

Exasol type (ANSI type)	Range (min.,max.)	Precision	Note
Exact numeric type
DECIMAL(p,s)		Precision, Scale: (p,s)	s ≤ p≤ 36 p ≥ 1 and s ≥ 0
Approximate numeric type
DOUBLE PRECISION		~15 digits	About 15 digits can be stored, independent of the scale. The special element NaN is interpreted as NULL, the element Infinity is not supported

Other considerations for data type TIMESTAMP(3) WITH LOCAL TIME ZONE

• In the case of TIMESTAMP(3) WITH LOCAL TIME ZONE columns, the timestamps are internally normalized to UTC, while the input and output values are interpreted in the session time zone. Hence, users in different time zones can easily insert and display data without worrying about internal storage. However, you should be aware that executing the same SQL statements in sessions with different time zones can lead to different results.

• While TIMESTAMP(3) is a simple structure consisting of a year, month, day, hour, minute, and second, data of type TIMESTAMP(3) WITH LOCAL TIME ZONE represents a specific moment on the time axis. Internally, the data is normalized to UTC because within certain time zones exist time shifts (for example, when switching from winter to summer time) and ambiguous periods (for example, when switching from summer to winter time). If such problematic data is inserted within the local session time zone, the session value TIME_ZONE_BEHAVIOR (changeable by ALTER SESSION) defines the course of action.

• Exasol stores the TIMESTAMP datatype in UTC and performs all computations involving the TIMESTAMP datatype in UTC.

  SQL clients using the Exasol JDBC driver may have their own time zone settings that affect how TIMESTAMP values are displayed. For more information, refer to the documentation for the respective SQL client.

The string for option TIME_ZONE_BEHAVIOR consists of two parts:

INVALID

When the time is set ahead in a time zone, then there is a gap. If timestamps are located within this gap, it can be treated in the following different ways:

SHIFT - Corrects the value by adding the daylight saving time offset (typically one hour)

ADJUST - Rounds the value to the first valid value after the time shift

NULLIFY - Sets the value to NULL

REJECT - Throws an exception

AMBIGUOUS

When the time is moved backward in a time zone, then ambiguous timestamps exist which can be treated in the following different ways:

ST - Interprets the value in Standard Time (ST)

DST - Interprets the values in Daylight Saving Time (DST)

NULLIFY - Sets the value to NULL

REJECT - Throws an exception

Therefore, the following combinations can be defined:

'INVALID SHIFT AMBIGUOUS ST'

'INVALID SHIFT AMBIGUOUS DST'

'INVALID SHIFT AMBIGUOUS NULLIFY'

'INVALID SHIFT AMBIGUOUS REJECT'

'INVALID ADJUST AMBIGUOUS ST'

'INVALID ADJUST AMBIGUOUS DST'

'INVALID ADJUST AMBIGUOUS NULLIFY'

'INVALID ADJUST AMBIGUOUS REJECT'

'INVALID NULLIFY AMBIGUOUS ST'

'INVALID NULLIFY AMBIGUOUS DST'

'INVALID NULLIFY AMBIGUOUS NULLIFY'

'INVALID NULLIFY AMBIGUOUS REJECT'

'INVALID REJECT AMBIGUOUS ST'

'INVALID REJECT AMBIGUOUS DST'

'INVALID REJECT AMBIGUOUS NULLIFY'

'INVALID REJECT AMBIGUOUS REJECT'

• When casting between the data types TIMESTAMP(3) WITH LOCAL TIME ZONE and TIMESTAMP(3), the session time zone is evaluated, and the TIMESTAMP WITH LOCAL TIME ZONE is transformed into a normal TIMESTAMP(3) data type. This is like displaying a TIMESTAMP(3) WITH LOCAL TIME ZONE value. For example, in your database client, the internal UTC normalized value is also converted to TIMESTAMP(3) data type, considering the session time zone.
• There are no special literals for the data type TIMESTAMP(3) WITH LOCAL TIME ZONE. The literal for data type TIMESTAMP(3) is considered, and the session time zone defines the corresponding moment on the time axis. For details about the arithmetic on datetime values and the datetime functions, see the Scalar Functions and Operators. For more information, see Literals.
• The timestamp values logged in statistical system tables are rendered in the database time zone (DBTIMEZONE). This is particularly relevant if you want to use the different functions for the current timestamp:

• The list of supported time zones can be found in the system table EXA_TIME_ZONES.

create table t1 (my_hash HASHTYPE);

insert into t1 values ('550e8400-e29b-11d4-a716-446655440000');
insert into t1 values ('{550e8400-e29b-11d4-a716-446655440000}');
insert into t1 values ('550e8400e29b11d4a716446655440000');
insert into t1 values ('550e-8400-e29b-11d4-a716-4466-5544-0000');
insert into t1 values ('VQ6EAOKbEdSnFkRmVUQAAA');

An empty string is evaluated as NULL value.

To display the character set of a certain column you can use the DESC[RIBE] command.

stringtype_definition::=