Information schema

Table of contents

• Access

• • tables

  • views

  • table_constraints

  • table_partitions

  • schemata

  • character_sets

When the user management is enabled, accessing the information_schema is open to all users and it does not require any privileges.

However, being able to query information_schema tables will not allow the user to retrieve all the rows in the table, as it can contain information related to tables over which the connected user does not have any privileges. The only rows that will be returned will be the ones the user is allowed to access.

For example, if the user john has any privilege on the doc.books table but no privilege at all on doc.locations, when john issues a SELECT * FROM information_schema.tables statement, the tables information related to the doc.locations table will not be returned.

Virtual tables

The information_schema.tables virtual table can be queried to get a list of all available tables and views and their settings, such as number of shards or number of replicas.

The table also contains additional information such as the specified and partition columns:

cr> SELECT table_name, clustered_by, partitioned_by
... FROM information_schema.tables
... WHERE table_schema = 'doc'
... ORDER BY table_schema ASC, table_name ASC;
+-------------------+--------------+----------------+
| table_name        | clustered_by | partitioned_by |
+-------------------+--------------+----------------+
| galaxies          | NULL         | NULL           |
| locations         | id           | NULL           |
| partitioned_table | _id          | ["date"]       |
| quotes            | id           | NULL           |
+-------------------+--------------+----------------+
SELECT 4 rows in set (... sec)

Schema

settings

Table settings specify configuration parameters for tables. Some settings can be set during Cluster runtime and others are only applied on cluster restart.

This list of table settings in shows detailed information of each parameter.

Table parameters can be applied with CREATE TABLE on creation of a table. With ALTER TABLE they can be set on already existing tables.

The following statement creates a new table and sets the refresh interval of shards to 500 ms and sets the shard allocation for primary shards only:

cr> create table parameterized_table (id integer, content text)
... with ("refresh_interval"=500, "routing.allocation.enable"='primaries');
CREATE OK, 1 row affected (... sec)

The settings can be verified by querying information_schema.tables:

cr> select settings['routing']['allocation']['enable'] as alloc_enable,
...   settings['refresh_interval'] as refresh_interval
... from information_schema.tables
... where table_name='parameterized_table';
+--------------+------------------+
| alloc_enable | refresh_interval |
+--------------+------------------+
| primaries    |              500 |
+--------------+------------------+
SELECT 1 row in set (... sec)

On existing tables this needs to be done with ALTER TABLE statement:

cr> alter table parameterized_table
... set ("routing.allocation.enable"='none');
ALTER OK, -1 rows affected (... sec)

views

The table information_schema.views contains the name, definition and options of all available views.

cr> SELECT table_schema, table_name, view_definition
... FROM information_schema.views
... ORDER BY table_schema ASC, table_name ASC;
+--------------+------------+-------------------------+
| table_schema | table_name | view_definition         |
+--------------+------------+-------------------------+
| doc          | galaxies   | SELECT                  |
|              |            |   "id"                  |
|              |            | , "name"                |
|              |            | , "description"         |
|              |            | FROM "locations"        |
|              |            | WHERE "kind" = 'Galaxy' |
+--------------+------------+-------------------------+
SELECT 1 row in set (... sec)

Schema

Note

If you drop the table of a view, the view will still exist and show up in the information_schema.tables and information_schema.views tables.

columns

This table can be queried to get a list of all available columns of all tables and views and their definition like data type and ordinal position inside the table:

cr> select table_name, column_name, ordinal_position as pos, data_type
... where table_schema = 'doc' and table_name not like 'my_table%'
... order by table_name asc, column_name asc;
+-------------------+--------------------------------+-----+--------------------------+
| table_name        | column_name                    | pos | data_type                |
+-------------------+--------------------------------+-----+--------------------------+
| locations         | date                           |   3 | timestamp with time zone |
| locations         | description                    |   6 | text                     |
| locations         | id                             |   1 | integer                  |
| locations         | information                    |  11 | object_array             |
| locations         | information['evolution_level'] |  12 | smallint                 |
| locations         | information['population']      |  13 | bigint                   |
| locations         | inhabitants                    |   7 | object                   |
| locations         | inhabitants['description']     |   8 | text                     |
| locations         | inhabitants['interests']       |   9 | text_array               |
| locations         | inhabitants['name']            |  10 | text                     |
| locations         | landmarks                      |  14 | text_array               |
| locations         | name                           |   2 | text                     |
| locations         | position                       |   5 | integer                  |
| partitioned_table | date                           |   3 | timestamp with time zone |
| partitioned_table | id                             |   1 | bigint                   |
| partitioned_table | title                          |   2 | text                     |
| quotes            | id                             |   1 | integer                  |
| quotes            | quote                          |   2 | text                     |
+-------------------+--------------------------------+-----+--------------------------+
SELECT 19 rows in set (... sec)

You can even query this table’s own columns (attention: this might lead to infinite recursion of your mind, beware!):

Schema

This table can be queried to get a list of all defined table constraints, their type, name and which table they are defined in.

Note

Currently only PRIMARY_KEY constraints are supported.

cr> select table_schema, table_name, constraint_name, constraint_type as type
... from information_schema.table_constraints
... where table_name = 'tables'
...   or table_name = 'quotes'
...   or table_name = 'documents'
...   or table_name = 'tbl'
... order by table_schema desc, table_name asc limit 10;
+--------------------+------------+-...------------------+-------------+
| table_schema       | table_name | constraint_name      | type        |
+--------------------+------------+-...------------------+-------------+
| information_schema | tables     | tables_pk            | PRIMARY KEY |
| doc                | quotes     | quotes_pk            | PRIMARY KEY |
| doc                | tbl        | doc_tbl_col_not_null | CHECK       |
+--------------------+------------+-...------------------+-------------+
SELECT 3 rows in set (... sec)

key_column_usage

This table may be queried to retrieve primary key information from all user tables:

cr> select constraint_name, table_name, column_name, ordinal_position
... from information_schema.key_column_usage
... where table_name = 'students'
+-----------------+------------+-------------+------------------+
| constraint_name | table_name | column_name | ordinal_position |
+-----------------+------------+-------------+------------------+
| students_pk     | students   | id          |                1 |
| students_pk     | students   | department  |                2 |
+-----------------+------------+-------------+------------------+
SELECT 2 rows in set (... sec)

Schema

table_partitions

This table can be queried to get information about all , Each partition of a table is represented as one row. The row contains the information table name, schema name, partition ident, and the values of the partition. values is a key-value object with the partition column (or columns) as key(s) and the corresponding value as value(s).

cr> insert into a_partitioned_table (id, content) values (1, 'content_a');
INSERT OK, 1 row affected (... sec)

cr> alter table a_partitioned_table set (number_of_shards=5);

cr> insert into a_partitioned_table (id, content) values (2, 'content_b');
INSERT OK, 1 row affected (... sec)

The following example shows a table where the column content of table a_partitioned_table has been used to partition the table. The table has two partitions. The partitions are introduced when data is inserted where content is content_a, and content_b.:

cr> select table_name, table_schema as schema, partition_ident, "values"
... from information_schema.table_partitions
... order by table_name, partition_ident;
+---------------------+--------+--------------------+--------------------------+
| table_name          | schema | partition_ident    | values                   |
+---------------------+--------+--------------------+--------------------------+
| a_partitioned_table | doc    | 04566rreehimst2vc4 | {"content": "content_a"} |
| a_partitioned_table | doc    | 04566rreehimst2vc8 | {"content": "content_b"} |
+---------------------+--------+--------------------+--------------------------+
SELECT 2 rows in set (... sec)

The second partition has been created after the number of shards for future partitions have been changed on the partitioned table, so they show 5 instead of 4:

The routines table contains tokenizers, token-filters, char-filters, custom analyzers created by CREATE ANALYZER statements (see ), and functions created by CREATE FUNCTION statements:

cr> select routine_name, routine_type
... from information_schema.routines
... group by routine_name, routine_type
+----------------------+--------------+
| routine_name         | routine_type |
+----------------------+--------------+
| PathHierarchy        | TOKENIZER    |
| apostrophe           | TOKEN_FILTER |
| arabic               | ANALYZER     |
| arabic_normalization | TOKEN_FILTER |
| arabic_stem          | TOKEN_FILTER |
+----------------------+--------------+
SELECT 5 rows in set (... sec)

For example you can use this table to list existing tokenizers like this:

cr> select routine_name
... from information_schema.routines
... where routine_type='TOKENIZER'
... order by routine_name asc limit 10;
+----------------+
| routine_name   |
+----------------+
| PathHierarchy  |
| char_group     |
| classic        |
| edge_ngram     |
| keyword        |
| letter         |
| lowercase      |
| ngram          |
| path_hierarchy |
| pattern        |
+----------------+
SELECT 10 rows in set (... sec)

Or get an overview of how many routines and routine types are available:

cr> select count(*), routine_type
... from information_schema.routines
... group by routine_type
... order by routine_type;
+----------+--------------+
| count(*) | routine_type |
+----------+--------------+
|       45 | ANALYZER     |
|        3 | CHAR_FILTER  |
|       16 | TOKENIZER    |
|       62 | TOKEN_FILTER |
+----------+--------------+
SELECT 4 rows in set (... sec)

Schema

routine_name

Name of the routine (might be duplicated in case of overloading)

routine_type

Type of the routine. Can be FUNCTION, ANALYZER, CHAR_FILTER, TOKEN_FILTER or TOKEN_FILTER.

routine_schema

The schema where the routine was defined. If it doesn’t apply, then NULL.

routine_body

The language used for the routine implementation. If it doesn’t apply, then NULL.

data_type

The return type of the function. If it doesn’t apply, then NULL.

is_deterministic

If the routine is deterministic then True, else False (NULL if it doesn’t apply).

routine_definition

The function definition (NULL if it doesn’t apply).

specific_name

Used to uniquely identify the function in a schema, even if the function is overloaded. Currently the specific name contains the types of the function arguments. As the format might change in the future, it should be only used to compare it to other instances of specific_name.

schemata

The schemata table lists all existing schemas. Thes blob, information_schema, and sys schemas are always available. The doc schema is available after the first user table is created.

cr> select schema_name from information_schema.schemata order by schema_name;
+--------------------+
| schema_name        |
+--------------------+
| blob               |
| doc                |
| information_schema |
| pg_catalog         |
| sys                |
+--------------------+
SELECT 5 rows in set (... sec)

sql_features

The sql_features table outlines supported and unsupported SQL features of CrateDB based to the current SQL standard (see ):

cr> select feature_name, is_supported, sub_feature_id, sub_feature_name
... from information_schema.sql_features
... where feature_id='F501';
+--------------------------------+--------------+----------------+--------------------+
| feature_name                   | is_supported | sub_feature_id | sub_feature_name   |
+--------------------------------+--------------+----------------+--------------------+
| Features and conformance views | FALSE        |                |                    |
| Features and conformance views | TRUE         | 1              | SQL_FEATURES view  |
| Features and conformance views | FALSE        | 2              | SQL_SIZING view    |
| Features and conformance views | FALSE        | 3              | SQL_LANGUAGES view |
+--------------------------------+--------------+----------------+--------------------+
SELECT 4 rows in set (... sec)

feature_id

Identifier of the feature

feature_name

Descriptive name of the feature by the Standard

sub_feature_id

Identifier of the subfeature; If it has zero-length, this is a feature

sub_feature_name

Descriptive name of the subfeature by the Standard; If it has zero-length, this is a feature

is_supported

YES if the feature is fully supported by the current version of CrateDB, NO if not

is_verified_by

Identifies the conformance test used to verify the claim;

Always NULL since the CrateDB development group does not perform formal testing of feature conformance

comments

Either NULL or shows a comment about the supported status of the feature

The character_sets table identifies the character sets available in the current database.

In CrateDB there is always a single entry listing UTF8:

cr> SELECT character_set_name, character_repertoire FROM information_schema.character_sets;
+--------------------+----------------------+
| character_set_name | character_repertoire |
+--------------------+----------------------+
| UTF8               | UCS                  |
SELECT 1 row in set (... sec)