OpenText Analytics Database 26.2.x – SET statements

Sql-Reference: SET DATESTYLE

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

Specifies how to format date/time output for the current session. Use SHOW DATESTYLE to verify the current output settings.

Syntax

SET DATESTYLE TO { arg | 'arg' }[, arg | 'arg' ]

Parameters

SET DATESTYLE has a single parameter, which can be set to one or two arguments that specify date ordering and style. Each argument can be specified singly or in combination with the other; if combined, they can be specified in any order.

The following table describes each style and the date ordering arguments it supports:

Date style arguments	Order arguments	Example
`ISO` (ISO 8601/SQL standard)	n/a	`2016-03-16 00:00:00`
`GERMAN`	n/a	`16.03.2016 00:00:00`
`SQL`	`MDY`	`03/16/2016 00:00:00`
`DMY` (default)	`16/03/2016 00:00:00`
`POSTGRES`	`MDY` (default)	`Wed Mar 16 00:00:00 2016`
`DMY`	`Wed 16 Mar 00:00:00 2016`

OpenText™ Analytics Database ignores the order argument for date styles ISO and GERMAN. If the date style is SQL or POSTGRES, the order setting determines whether dates are output in MDY or DMY order. Neither SQL nor POSTGRES support YMD order. If you specify YMD for SQL or POSTGRES, the database ignores it and uses their default MDY order.

Date styles and ordering can also affect how the database interprets input values. For more information, see Date/time literals.

Privileges

None

Input dependencies

In some cases, input format can determine output, regardless of date style and order settings:

The ISO output for DATESTYLE is ISO long form, but several input styles are accepted. If the year appears first in the input, YMD is used for input and output, regardless of the DATESTYLE value.
INTERVAL input and output share the same format, with the following exceptions:
- Units like CENTURY or WEEK are converted to years and days.
- AGO is converted to the appropriate sign.
If the date style is set to ISO, output follows this format:
```
[ quantity unit [...] ] [ days ] [ hours:minutes:seconds ]
```

Examples

=> CREATE TABLE t(a DATETIME);
CREATE TABLE
=> INSERT INTO t values ('3/16/2016');
 OUTPUT
--------
      1
(1 row)

=> SHOW DATESTYLE;
   name    | setting
-----------+----------
 datestyle | ISO, MDY
(1 row)

=> SELECT * FROM t;
          a
---------------------
 2016-03-16 00:00:00
(1 row)

=> SET DATESTYLE TO German;
SET
=> SHOW DATESTYLE;
   name    |   setting
-----------+-------------
 datestyle | German, DMY
(1 row)

=> SELECT * FROM t;
          a
---------------------
 16.03.2016 00:00:00
(1 row)

=> SET DATESTYLE TO SQL;
SET
=> SHOW DATESTYLE;
   name    | setting
-----------+----------
 datestyle | SQL, DMY
(1 row)

=> SELECT * FROM t;
          a
---------------------
 16/03/2016 00:00:00
(1 row)

=> SET DATESTYLE TO Postgres, MDY;
SET
=> SHOW DATESTYLE;
   name    |    setting
-----------+---------------
 datestyle | Postgres, MDY
(1 row)

=> SELECT * FROM t;
            a
--------------------------
 Wed Mar 16 00:00:00 2016
(1 row)

Sql-Reference: SET ESCAPE_STRING_WARNING

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

Issues a warning when a backslash is used in a string literal during the current session.

Syntax

SET ESCAPE_STRING_WARNING TO { ON | OFF }

Parameters

ON: [Default] Issues a warning when a back slash is used in a string literal.
Tip: Organizations that have upgraded from earlier versions of OpenText™ Analytics Database can use this as a debugging tool for locating backslashes that used to be treated as escape characters, but are now treated as literals.
OFF: Ignores back slashes within string literals.

Privileges

None

Notes

This statement works under vsql only.
Turn off standard conforming strings before you turn on this parameter.

Tip

To set escape string warnings across all sessions, use the EscapeStringWarnings configuration parameter. See the Internationalization parameters.

Examples

The following example shows how to turn OFF escape string warnings for the session.

=> SET ESCAPE_STRING_WARNING TO OFF;

Sql-Reference: SET INTERVALSTYLE

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

Specifies whether to include units in interval output for the current session.

Syntax

SET INTERVALSTYLE TO [ plain | units ]

Parameters

plain: (default) Sets the default interval output to omit units.
units: Enables interval output to include subtype unit identifiers. When INTERVALSTYLE is set to units, the DATESTYLE parameter controls output. If you enable units and they do not display in the output, check the DATESTYLE parameter value, which must be set to ISO or POSTGRES for interval units to display.

Privileges

None

Examples

See Setting interval unit display.

Sql-Reference: SET LOCALE

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

Specifies locale for the current session.

You can also set the current locale with the vsql command \locale.

Syntax

SET LOCALE TO ICU-locale-identifier

Parameters

locale-identifier

Specifies the ICU locale identifier to use, by default set to:

en_US@collation=binary

If set to an empty string, OpenText™ Analytics Database sets locale to en_US_POSIX.

The following requirements apply:

The database only supports the COLLATION keyword.
Single quotes are mandatory to specify collation.

Privileges

None

Commonly used locales

For details on identifier options, see About locale. For a complete list of locale identifiers, see the ICU Project.

de_DE: German (Germany)
en_GB: English (Great Britain)
es_ES: Spanish (Spain)
fr_FR: French (France)
pt_BR: Portuguese (Brazil)
pt_PT: Portuguese (Portugal)
ru_RU: Russian (Russia)
ja_JP: Japanese (Japan)
zh_CN: Chinese (China, simplified Han)
zh_Hant_TW: Chinese (Taiwan, traditional Han)

Examples

Set session locale to en_GB:

=> SET LOCALE TO en_GB;
INFO 2567:  Canonical locale: 'en_GB'
Standard collation: 'LEN'
English (United Kingdom)
SET

Use the short form of a locale:

=> SET LOCALE TO LEN;
INFO 2567:  Canonical locale: 'en'
Standard collation: 'LEN'
English
SET

Specify collation:

=> SET LOCALE TO 'tr_tr@collation=standard';
INFO 2567:  Canonical locale: 'tr_TR@collation=standard'
Standard collation: 'LTR'
Turkish (Turkey, collation=standard)  Türkçe (Türkiye, Sıralama=standard)
SET

Sql-Reference: SET ROLE

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

Enables a role for the user's current session. The user can access privileges that have been granted to the role. Enabling a role has no effect on roles that are currently enabled.

Tip

Use SHOW AVAILABLE ROLES to list granted roles.

Syntax

SET ROLE roles-expression

Parameters

roles-expression

Specifies what roles are the default roles for this user, with one of the following expressions:

NONE (default): Disables all roles.
roles-list: A comma-delimited list of roles to enable. You can only set roles that are currently granted to you.
ALL [EXCEPT roles-list]: Enables all roles currently granted to this user, excluding any comma-delimited roles specified in the optional EXCEPT clause.
DEFAULT: Enables all default roles. Default roles are, by definition, enabled automatically, but this option might be useful for re-enabling them if they are disabled with SET ROLE NONE.

Privileges

None

Examples

This example shows the following:

SHOW AVAILABLE_ROLES; lists the roles available to the user, but not enabled.
SET ROLE applogs; enables the applogs role for the user.
SHOW ENABLED_ROLES; lists the applogs role as enabled (SET) for the user.
SET ROLE appuser; enables the appuser role for the user.
SHOW ENABLED_ROLES now lists both applogs and appuser as enabled roles for the user.
SET ROLE NONE disables all the users' enabled roles .
SHOW ENABLED_ROLES shows that no roles are enabled for the user.


=> SHOW AVAILABLE_ROLES;
      name       |          setting
-----------------+----------------------------
 available roles | applogs, appadmin, appuser
(1 row)

=> SET ROLE applogs;
SET
=> SHOW ENABLED_ROLES;
     name      | setting
---------------+---------
 enabled roles | applogs
(1 row)

=> SET ROLE appuser;
SET
=> SHOW ENABLED_ROLES;
     name      |     setting
---------------+------------------
 enabled roles | applogs, appuser
(1 row)

=> SET ROLE NONE;
SET


=> SHOW ENABLED_ROLES;
     name      | setting
---------------+---------
 enabled roles |
(1 row)

Set User Default Roles

Though the DBADMIN user is normally responsible for setting a user's default roles, as a user you can set your own role. For example, if you run SET ROLE NONE all of your enabled roles are disabled. Then it was determined you need access to role1 as a default role. The DBADMIN uses ALTER USER to assign you a default role:

=> ALTER USER user1 default role role1;

This example sets role1 as user1's default role because the DBADMIN assigned this default role using ALTER USER.

user1 => SET ROLE default;
user1 => SHOW ENABLED_ROLES;
    name      | setting
-----------------------
enabled roles |   role1
(1 row)

Set All Roles as Default

This example makes all roles granted to user1 default roles:

user1 => SET ROLE all;
user1 => show enabled roles;
    name      |   setting
----------------------------------
enabled roles | role1, role2, role3
(1 row)

Set All Roles as Default With EXCEPT

This example makes all the roles granted to the user default roles with the exception of role1.

user1 => set role all except role1;
user1 => SHOW ENABLED_ROLES
     name     | setting
----------------------------
enabled roles | role2, role3
(1 row)

Sql-Reference: SET SEARCH_PATH

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

Specifies the order in which OpenText™ Analytics Database searches schemas when a SQL statement specifies a table name that is unqualified by a schema name. SET SEARCH_PATH overrides the current session's search path, which is initially set from the user profile. This search path remains in effect until the next SET SEARCH_PATH statement, or the session ends. For details, see Setting search paths.

To view the current search path, use SHOW SEARCH_PATH.

Syntax

SET SEARCH_PATH { TO | = } { schema-list | DEFAULT }

Parameters

schema-list

A comma-delimited list of schemas that indicates the order in which the database searches schemas for a table whose name is unqualified by a schema name.

If the search path includes a schema that does not exist, or for which the user lacks access privileges, the database silently skips over that schema.

DEFAULT

Sets the search path to the database default:

"$user", public, v_catalog, v_monitor, v_internal

Privileges

None

Examples

Show the current search path:

=> SHOW SEARCH_PATH;
    name     |                      setting
-------------+---------------------------------------------------
 search_path | "$user", public, v_catalog, v_monitor, v_internal
(1 row)

Reset the search path to schemas store and public:

=> SET SEARCH_PATH TO store, public;
=> SHOW SEARCH_PATH;
    name     |                     setting
-------------+-------------------------------------------------
 search_path | store, public, v_catalog, v_monitor, v_internal
(1 row)

Reset the search path to the database default settings:

=> SET SEARCH_PATH TO DEFAULT;
SET
=> SHOW SEARCH_PATH;
    name     |                      setting
-------------+---------------------------------------------------
 search_path | "$user", public, v_catalog, v_monitor, v_internal
(1 row)

Sql-Reference: SET SESSION AUTHORIZATION

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

Sets the current and session user for the current database connection. You can change session authorization to execute queries as another user for testing or debugging purposes, or to limit query access.

Syntax

SET SESSION AUTHORIZATION { username | DEFAULT }

Parameters

username: The name of the user that you want to authorize for the current SQL session.
DEFAULT: Sets session authorization to the dbadmin user.

Privileges

Superuser

Examples

In the following example, the dbadmin gives the debuguser user session authorization, and then changes the session authorization back to the dbadmin user.

Verify the current user and session user:

=> SELECT CURRENT_USER(), SESSION_USER();
 current_user | session_user
--------------+--------------
 dbadmin      | dbadmin
(1 row)

Set authorization for the current session to debuguser, and verify the changes:

=> SET SESSION AUTHORIZATION debuguser;
SET
=> SELECT CURRENT_USER(), SESSION_USER();
 current_user | session_user
--------------+--------------
 debuguser    | debuguser
(1 row)

After you complete debugging tasks, set the session authorization to DEFAULT to set the current and session user back to dbadmin user, and verify the changes:

=> SET SESSION AUTHORIZATION DEFAULT;
SET
=> SELECT CURRENT_USER(), SESSION_USER();
 current_user | session_user
--------------+--------------
 dbadmin      | dbadmin
(1 row)

Sql-Reference: SET SESSION AUTOCOMMIT

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

Sets whether statements automatically commit their transactions on completion. This statement is primarily used by the client drivers to enable and disable autocommit, you should never have to directly call it.

Syntax

SET SESSION AUTOCOMMIT TO { ON | OFF }

Parameters

ON: Enable autocommit. Statements automatically commit their transactions when they complete. This is the default setting for connections made using the OpenText™ Analytics Database client libraries.
OFF: Disable autocommit. Transactions are not automatically committed. This is the default for interactive sessions (connections made through vsql).

Privileges

None

Examples

This examples show how to set AUTOCOMMIT to 'on' and then to 'off'.

=> SET SESSION AUTOCOMMIT TO on;
SET
=> SET SESSION AUTOCOMMIT TO off;
SET

Sql-Reference: SET SESSION CHARACTERISTICS AS TRANSACTION

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

Sets the isolation level and access mode of all transactions that start after this statement is issued.

A transaction retains its isolation level until it completes, even if the session's isolation level changes during the transaction. OpenText™ Analytics Database internal processes (such as the Tuple Mover and refresh operations) and DDL operations always run at the SERIALIZABLE isolation level to ensure consistency.

Syntax

SET SESSION CHARACTERISTICS AS TRANSACTION settings

settings

One or both of the following:

ISOLATION LEVEL argument

READ ONLY | READ WRITE

ISOLATION LEVEL arguments

The ISOLATION LEVEL clause determines what data the transaction can access when other transactions run concurrently. You cannot change the isolation level after the first query (SELECT) or DML statement (INSERT, DELETE, UPDATE) if a transaction has run.

Set ISOLATION LEVEL to one of the following arguments:

SERIALIZABLE

Sets the strictest level of SQL transaction isolation. This level emulates transactions serially, rather than concurrently. It holds locks and blocks write operations until the transaction completes.

Applications that use SERIALIZABLE must be prepared to retry transactions in the event of serialization failures. This isolation level is not recommended for normal query operations.

Setting the transaction isolation level to SERIALIZABLE does not apply to temporary tables. Temporary tables are isolated by their transaction scope.

REPEATABLE READ

Automatically converted to SERIALIZABLE.

READ COMMITTED

Default, allows concurrent transactions.

READ UNCOMMITTED

Automatically converted to READ COMMITTED.

READ WRITE/READ ONLY

You can set the transaction access mode with one of the following:

READ WRITE

Default, allows read/write access to SQL statements.

READ ONLY

Disallows SQL statements that require write access:

INSERT, UPDATE, DELETE, and COPY operations on any non-temporary table.
CREATE, ALTER, and DROP
GRANT, REVOKE
EXPLAIN if the SQL statement to explain requires write access.

Note

Setting the transaction session mode to read-only does not prevent all write operations.

Privileges

None

Viewing session transaction characteristics

SHOW TRANSACTION_ISOLATION and SHOW TRANSACTION_READ_ONLY show the transaction settings for the current session:

=> SHOW TRANSACTION_ISOLATION;
         name          |   setting
-----------------------+--------------
 transaction_isolation | SERIALIZABLE
(1 row)

=> SHOW TRANSACTION_READ_ONLY;
         name          | setting
-----------------------+---------
 transaction_read_only | true
(1 row)

Sql-Reference: SET SESSION GRACEPERIOD

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

Sets how long a session socket remains blocked while awaiting client input or output for a given query. If the socket is blocked for a continuous period that exceeds the grace period setting, the server shuts down the socket and throws a fatal error. The session is then terminated. If no grace period is set, the query can maintain its block on the socket indefinitely.

OpenText™ Analytics Database applies a session's grace period and RUNTIMECAP settings independently. If no grace period is set, a query can continue to block indefinitely on a session socket, regardless of the query's RUNTIMECAP setting.

Syntax

SET SESSION GRACEPERIOD duration

Parameters

duration

Specifies how long a query can block on any session socket, one of the following:

'interval': Specifies as an interval the maximum grace period for current session queries, up to 20 days.
=DEFAULT: Sets the grace period for queries in this session to the user's GRACEPERIOD value. A new session is initially set to this value.
NONE: Valid only for superusers, removes any grace period previously set on session queries.

Privileges

Superusers can increase session grace period to any value, regardless of database or node settings.
Non-superusers can only set the session grace period to a value equal to or lower than their own user setting. If no grace period is explicitly set for a user, the grace period for that user is inherited from the node or database settings.

Examples

See Handling session socket blocking in the Administrator's Guide.

Sql-Reference: SET SESSION IDLESESSIONTIMEOUT

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

Sets the maximum amount of time that a session can remain idle before it exits.

Note

An idle session has no queries running.

Syntax

SET SESSION IDLESESSIONTIMEOUT duration

Parameters

duration

Specifies the amount of time a session can remain idle before it exits:

NONE (default): No idle timeout set on the session.
'interval': Specifies as an interval the maximum amount of time a session can remain idle.
=DEFAULT: Sets the idle timeout period for this session to the user's IDLESESSIONTIMEOUT value.

Privileges

Superusers can increase the time a session can remain idle to any value, regardless of database or node settings.
Non-superusers can only set the session idle time to a value equal to or lower than their own user setting. If no session idle time is explicitly set for a user, the session idle time for that user is inherited from the node or database settings.

Examples

See Managing client connections in the Administrator's Guide.

Sql-Reference: SET SESSION MEMORYCAP

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

Limits how much memory can be allocated to any request in the current session. This limit only applies to the current session; it does not limit the total amount of memory used by multiple sessions.

Syntax

SET SESSION MEMORYCAP limit

Parameters

limit

One of the following:

'max-expression': A string value that specifies the memory limit, one of the following:
- int% — Expresses the maximum as a percentage of total memory available to the Resource manager, where int is an integer value between 0 and 100.For example:
  
  MEMORYCAP '40%'
- int{K|M|G|T} — Expresses memory allocation in kilobytes, megabytes, gigabytes, or terabytes. For example:
  
  MEMORYCAP '10G'
=DEFAULT: Sets the memory cap for queries in this session to the user's MEMORYCAP value.A new session is initially set to this value.
NONE: Removes the memory cap for this session.

Privileges

Superusers can increase session memory cap to any value.
Non-superusers can only set the session memory cap to a value equal to or lower than their own user setting.

Examples

Set the session memory cap to 2 gigabytes:

=> SET SESSION MEMORYCAP '2G';
SET
=> SHOW MEMORYCAP;
   name    | setting
-----------+---------
 memorycap | 2097152
(1 row)

Revert the memory cap to the default setting as specified in the user profile:


=> SET MEMORYCAP=DEFAULT;
SET
=> SHOW MEMORYCAP;
   name    | setting
-----------+---------
 memorycap | 2013336
(1 row)

Sql-Reference: SET SESSION MULTIPLEACTIVERESULTSETS

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

Enables or disable the execution of multiple active result sets (MARS) on a single JDBC connection. Using this option requires an active JDBC connection.

Syntax

SET SESSION MULTIPLEACTIVERESULTSETS TO { ON | OFF }

Parameters

ON: Enable MultipleActiveResultSets.Allows you to execute multiple result sets on a single connection.
OFF: Disable MultipleActiveResultSets. Allows only one active result set per connection.(Default value.)

Privileges

None

Examples

This example shows how you can set MultipleActiveResultSets to on and then to off:

=> SET SESSION MULTIPLEACTIVERESULTSETS TO on;
SET
=> SET SESSION MULTIPLEACTIVERESULTSETS TO off;
SET

Sql-Reference: SET SESSION RESOURCE_POOL

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

Associates the user session with the specified resource pool.

Syntax

SET SESSION RESOURCE_POOL = { pool-name | DEFAULT }

Parameters

pool-name: The name of an existing resource pool to associate with the current session. Non-superusers must have USAGE privileges on the specified resource pool.
DEFAULT: Sets the session's resource pool to the resource pool assigned to this user.

Privileges

None

Examples

This example sets ceo_pool as the session resource pool:

=> SET SESSION RESOURCE_POOL = ceo_pool;
SET

Sql-Reference: SET SESSION RUNTIMECAP

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

Sets the maximum amount of time queries and stored procedures can run in a given session. If a query or stored procedure exceeds its session's RUNTIMECAP, OpenText™ Analytics Database terminates it and returns an error. You cannot increase the RUNTIMECAP beyond the limit that is set in your user profile.

Note

The database does not strictly enforce session RUNTIMECAP settings. If you time a query or stored procedure, you might discover that it runs longer than the RUNTIMECAP setting.

Syntax

SET SESSION RUNTIMECAP duration

Parameters

duration

Specifies how long a given query can run in the current session, one of the following:

NONE (default): Removes a runtime limit for all current session queries.
'interval': Specifies as an interval the maximum runtime for current session queries, up to one year—for example, 1 minute or 100 seconds.
=DEFAULT: Sets maximum runtime for queries in this session to the user's RUNTIMECAP value.

Privileges

Superusers can increase session RUNTIMECAP to any value.
Non-superusers can only set the session RUNTIMECAP to a value equal to or lower than their own user RUNTIMECAP.

Examples

Set the maximum query runtime for the current session to 10 minutes:

=> SET SESSION RUNTIMECAP '10 minutes';

Revert the session RUNTIMECAP to your user default setting:

=> SET SESSION RUNTIMECAP =DEFAULT;
SET
=> SHOW RUNTIMECAP;
    name    |  setting
------------+-----------
 runtimecap | UNLIMITED
(1 row)

Set the RUNTIMECAP to 1 SECOND and run an anonymous procedure with an infinite loop:

=> SET SESSION RUNTIMECAP '1 SECOND';
SET

=> DO $$
BEGIN
    LOOP
    END LOOP;
END;
$$;

ERROR 0:  Query exceeded maximum runtime
HINT:  Change the maximum runtime using SET SESSION RUNTIMECAP

Sql-Reference: SET SESSION TEMPSPACECAP

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

Sets the maximum amount of temporary file storage that any request issued by the session can consume. If a query's execution plan requires more storage space than the session TEMPSPACECAP, it returns an error.

Syntax

SET SESSION TEMPSPACECAP limit

Arguments

limit

The maximum amount of temporary file storage to allocate to the current session, one of the following:

NONE (default): Unlimited temporary storage
= DEFAULT: Session TEMPSPACECAP is set to the user's TEMPSPACECAP value.
String that specifies the storage limit, one of the following:
- int% expresses the maximum as a percentage of total temporary storage available to the Resource Manager, where int is an integer value between 0 and 100. For example:
```
SET SESSION TEMPSPACECAP '40%';
```
- int{K|M|G|T} expresses storage allocation in kilobytes, megabytes, gigabytes, or terabytes. For example:
```
SET SESSION TEMPSPACECAP '10G';
```

Privileges

Non-superusers:

Restricted to setting only their own sessions
Session TEMPSPACECAP cannot be greater than their own TEMPSPACECAP.

Examples

Set the session TEMPSPACECAP to 20 gigabytes:

=> SET SESSION TEMPSPACECAP '20G';
SET
=> SHOW TEMPSPACECAP;
     name     | setting
--------------+----------
 tempspacecap | 20971520
(1 row)

Note

SHOW displays the TEMPSPACECAP in kilobytes.

Set the session TEMPSPACECAP to unlimited:

=> SET SESSION TEMPSPACECAP NONE;
SET
=> SHOW TEMPSPACECAP;
     name     |  setting
--------------+-----------
 tempspacecap | UNLIMITED
(1 row)

Sql-Reference: SET SESSION WORKLOAD

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

Sets the workload for the current session.

For details on this and other session parameters, see SHOW:

Syntax

SET SESSION WORKLOAD TO { workload_name | DEFAULT | NONE }

Parameters

workload_name: The workload to use for the current session. The specified workload must be associated with a workload routing rule.
DEFAULT: Sets the workload to the workload granted to the current user or their roles. If they have more than one workload, the one with the highest priority is used.
NONE: Removes the workload for the current session.

Privileges

None

Examples

The following example sets analytics as the workload for the current session:

=> CREATE ROUTING RULE analytic_rule ROUTE WORKLOAD analytics TO SUBCLUSTER my_subcluster;
=> SET SESSION WORKLOAD analytics;

Sql-Reference: SET STANDARD_CONFORMING_STRINGS

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

Specifies whether to treat backslashes as escape characters for the current session. By default, OpenText™ Analytics Database conforms to the SQL standard and supports SQL:2008 string literals within Unicode escapes.

Syntax

SET STANDARD_CONFORMING_STRINGS TO { ON | OFF }

Parameters

ON: (Default) Treat ordinary string literals ('...') as backslashes () literally. This means that backslashes are treated as string literals and not as escape characters.
OFF: Treat backslashes as escape characters.

Privileges

None

Requirements

This statement works under vsql only.
Standard-conforming strings must be ON to use Unicode-style string literals (U&'\nnnn').

Tip

You can set conforming strings across all sessions by setting the configuration parameter StandardConformingStrings with ALTER DATABASE...SET PARAMETER.

Examples

Turn off conforming strings for the session:

=> SET STANDARD_CONFORMING_STRINGS TO OFF;

Verify the current setting:

=> SHOW STANDARD_CONFORMING_STRINGS;
            name             | setting
-----------------------------+---------
 standard_conforming_strings | off
(1 row)

Turn on conforming strings for the session:

=> SET STANDARD_CONFORMING_STRINGS TO ON;

Sql-Reference: SET TIME ZONE

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

Changes the TIME ZONE run-time parameter for the current session. Use SHOW TIMEZONE to show the session's current time zone.

If you set the timezone using POSIX format, the timezone abbreviation you use overrides the default timezone abbreviation. If the date style is set to POSTGRES, the timezone abbreviation you use is also used when converting a timestamp to a string.

Syntax

SET TIME ZONE [TO] { value | 'value' }

Note

OpenText™ Analytics Database treats literals TIME ZONE and TIMEZONE as synonyms.

Parameters

value

One of the following:

A time zone literal supported by the database. To view the default list of valid literals, see the files in the following directory:
```
/opt/vertica/share/timezonesets
```
A signed integer representing an offset from UTC in hours
A time zone literal with a signed integer offset. For example:
```
=> SET TIME ZONE TO 'America/New York -3'; -- equivalent to Pacific time
```
Note
Only valid timezone+offset combinations are meaningful as arguments to SET TIME ZONE. However, the database does not return an error for meaningless combinations—for example, America/NewYork + 150.
An interval value
Constants LOCAL and DEFAULT, which respectively set the time zone to the one specified in environment variable TZ, or if TZ is undefined, to the operating system time zone.

Only valid (timezone+offset) combination are acceptable as parameter for this function.

Privileges

None

Examples

=> SET TIME ZONE TO DEFAULT;
=> SET TIME ZONE TO 'PST8PDT'; -- Berkeley, California
=> SET TIME ZONE TO 'Europe/Rome'; -- Italy
=> SET TIME ZONE TO '-7'; -- UDT offset equivalent to PDT
=> SET TIME ZONE TO INTERVAL '-08:00 HOURS';

OpenText Analytics Database 26.2.x – SET statements

Sql-Reference: SET DATESTYLE

Syntax

Parameters

Privileges

Input dependencies

Examples

Sql-Reference: SET ESCAPE_STRING_WARNING

Syntax

Parameters

Privileges

Notes

Tip

Examples

See also

Sql-Reference: SET INTERVALSTYLE

Syntax

Parameters

Privileges

Examples

Sql-Reference: SET LOCALE

Syntax

Parameters

Privileges

Commonly used locales

Examples

See also

Sql-Reference: SET ROLE

Tip

Syntax

Parameters

Privileges

Examples

Sql-Reference: SET SEARCH_PATH

Syntax

Parameters

Privileges

Examples

Sql-Reference: SET SESSION AUTHORIZATION

Syntax

Parameters

Privileges

Examples

Sql-Reference: SET SESSION AUTOCOMMIT

Syntax

Parameters

Privileges

Examples

See also

Sql-Reference: SET SESSION CHARACTERISTICS AS TRANSACTION

Syntax

ISOLATION LEVEL arguments

READ WRITE/READ ONLY

Note

Privileges

Viewing session transaction characteristics

Sql-Reference: SET SESSION GRACEPERIOD

Syntax

Parameters

Privileges

Examples

Sql-Reference: SET SESSION IDLESESSIONTIMEOUT

Note

Syntax

Parameters

Privileges

Examples

Sql-Reference: SET SESSION MEMORYCAP

Syntax

Parameters

Privileges

Examples

See also

Sql-Reference: SET SESSION MULTIPLEACTIVERESULTSETS

Syntax

Parameters

Privileges

Examples

Sql-Reference: SET SESSION RESOURCE_POOL

Syntax