8.16. Составные типы
Составной тип представляет структуру табличной строки или записи; по сути это просто список имён полей и соответствующих типов данных. Postgres Pro позволяет использовать составные типы во многом так же, как и простые типы. Например, в определении таблицы можно объявить столбец составного типа.
8.16.1. Объявление составных типов
Ниже приведены два простых примера определения составных типов:
CREATE TYPE complex AS ( r double precision, i double precision ); CREATE TYPE inventory_item AS ( name text, supplier_id integer, price numeric );
Синтаксис очень похож на CREATE TABLE
, за исключением того, что он допускает только названия полей и их типы, какие-либо ограничения (такие как NOT NULL
) в настоящее время не поддерживаются. Заметьте, что ключевое слово AS
здесь имеет значение; без него система будет считать, что подразумевается другой тип команды CREATE TYPE
, и выдаст неожиданную синтаксическую ошибку.
Определив такие типы, мы можем использовать их в таблицах:
CREATE TABLE on_hand ( item inventory_item, count integer ); INSERT INTO on_hand VALUES (ROW('fuzzy dice', 42, 1.99), 1000);
или функциях:
CREATE FUNCTION price_extension(inventory_item, integer) RETURNS numeric AS 'SELECT $1.price * $2' LANGUAGE SQL; SELECT price_extension(item, 10) FROM on_hand;
Всякий раз, когда создаётся таблица, вместе с ней автоматически создаётся составной тип. Этот тип представляет тип строки таблицы, и его именем становится имя таблицы. Например, при выполнении команды:
CREATE TABLE inventory_item ( name text, supplier_id integer REFERENCES suppliers, price numeric CHECK (price > 0) );
в качестве побочного эффекта будет создан составной тип inventory_item
, в точности соответствующий тому, что был показан выше, и использовать его можно так же. Однако заметьте, что в текущей реализации есть один недостаток: так как с составным типом не могут быть связаны ограничения, то описанные в определении таблицы ограничения не применяются к значениям составного типа вне таблицы. (Чтобы обойти этот недостаток, создайте домен поверх составного типа и добавьте желаемые ограничения в виде ограничений CHECK
для данного домена.)
8.16.2. Конструирование составных значений
Чтобы записать значение составного типа в виде текстовой константы, его поля нужно заключить в круглые скобки и разделить их запятыми. Значение любого поля можно заключить в кавычки, а если оно содержит запятые или скобки, это делать обязательно. (Подробнее об этом говорится ниже.) Таким образом, в общем виде константа составного типа записывается так:
'(значение1
,значение2
, ... )'
Например, эта запись:
'("fuzzy dice",42,1.99)'
будет допустимой для описанного выше типа inventory_item
. Чтобы присвоить NULL одному из полей, в соответствующем месте в списке нужно оставить пустое место. Например, эта константа задаёт значение NULL для третьего поля:
'("fuzzy dice",42,)'
Если же вместо NULL требуется вставить пустую строку, нужно записать пару кавычек:
'("",42,)'
Здесь в первом поле окажется пустая строка, а в третьем — NULL.
(Такого рода константы массивов на самом деле представляют собой всего лишь частный случай констант, описанных в Подразделе 4.1.2.7. Константа изначально воспринимается как строка и передаётся процедуре преобразования составного типа. При этом может потребоваться явно указать тип, к которому будет приведена константа.)
Значения составных типов также можно конструировать, используя синтаксис выражения ROW
. В большинстве случаев это значительно проще, чем записывать значения в строке, так как при этом не нужно беспокоиться о вложенности кавычек. Мы уже обсуждали этот метод ранее:
ROW('fuzzy dice', 42, 1.99) ROW('', 42, NULL)
Ключевое слово ROW на самом деле может быть необязательным, если в выражении определяются несколько полей, так что эту запись можно упростить до:
('fuzzy dice', 42, 1.99) ('', 42, NULL)
Синтаксис выражения ROW
более подробно рассматривается в Подразделе 4.2.13.
8.16.3. Обращение к составным типам
Чтобы обратиться к полю столбца составного типа, после имени столбца нужно добавить точку и имя поля, подобно тому, как указывается столбец после имени таблицы. На самом деле, эти обращения неотличимы, так что часто бывает необходимо использовать скобки, чтобы команда была разобрана правильно. Например, можно попытаться выбрать поле столбца из тестовой таблицы on_hand
таким образом:
SELECT item.name FROM on_hand WHERE item.price > 9.99;
Но это не будет работать, так как согласно правилам SQL имя item
здесь воспринимается как имя таблицы, а не столбца в таблице on_hand
. Поэтому этот запрос нужно переписать так:
SELECT (item).name FROM on_hand WHERE (item).price > 9.99;
либо указать также и имя таблицы (например, в запросе с многими таблицами), примерно так:
SELECT (on_hand.item).name FROM on_hand WHERE (on_hand.item).price > 9.99;
В результате объект в скобках будет правильно интерпретирован как ссылка на столбец item
, из которого выбирается поле.
При выборке поля из значения составного типа также возможны подобные синтаксические казусы. Например, чтобы выбрать одно поле из результата функции, возвращающей составное значение, потребуется написать что-то подобное:
SELECT (my_func(...)).field FROM ...
Без дополнительных скобок в этом запросе произойдёт синтаксическая ошибка.
Специальное имя поля *
означает «все поля»; подробнее об этом рассказывается в Подразделе 8.16.5.
8.16.4. Изменение составных типов
Ниже приведены примеры правильных команд добавления и изменения значений составных столбцов. Первые команды иллюстрируют добавление или изменение всего столбца:
INSERT INTO mytab (complex_col) VALUES((1.1,2.2)); UPDATE mytab SET complex_col = ROW(1.1,2.2) WHERE ...;
В первом примере опущено ключевое слово ROW
, а во втором оно есть; присутствовать или отсутствовать оно может в обоих случаях.
Мы можем изменить также отдельное поле составного столбца:
UPDATE mytab SET complex_col.r = (complex_col).r + 1 WHERE ...;
Заметьте, что при этом не нужно (и на самом деле даже нельзя) заключать в скобки имя столбца, следующее сразу за предложением SET
, но в ссылке на тот же столбец в выражении, находящемся по правую сторону знака равенства, скобки обязательны.
И мы также можем указать поля в качестве цели команды INSERT
:
INSERT INTO mytab (complex_col.r, complex_col.i) VALUES(1.1, 2.2);
Если при этом мы не укажем значения для всех полей столбца, оставшиеся поля будут заполнены значениями NULL.
8.16.5. Использование составных типов в запросах
С составными типами в запросах связаны особые правила синтаксиса и поведение. Эти правила образуют полезные конструкции, но они могут быть неочевидными, если не понимать стоящую за ними логику.
В Postgres Pro ссылка на имя таблицы (или её псевдоним) в запросе по сути является ссылкой на составное значение текущей строки в этой таблице. Например, имея таблицу inventory_item
, показанную выше, мы можем написать:
SELECT c FROM inventory_item c;
Этот запрос выдаёт один столбец с составным значением, и его результат может быть таким:
c ------------------------ ("fuzzy dice",42,1.99) (1 row)
Заметьте, однако, что простые имена сопоставляются сначала с именами столбцов, и только потом с именами таблиц, так что такой результат получается только потому, что в таблицах запроса не оказалось столбца с именем c
.
Обычную запись полного имени столбца вида имя_таблицы
.
имя_столбца
можно понимать как применение выбора поля к составному значению текущей строки таблицы. (Из соображений эффективности на самом деле это реализовано по-другому.)
Когда мы пишем
SELECT c.* FROM inventory_item c;
то, согласно стандарту SQL, мы должны получить содержимое таблицы, развёрнутое в отдельные столбцы:
name | supplier_id | price ------------+-------------+------- fuzzy dice | 42 | 1.99 (1 row)
как с запросом
SELECT c.name, c.supplier_id, c.price FROM inventory_item c;
Postgres Pro применяет такое развёртывание для любых выражений с составными значениями, хотя как показано выше, необходимо заключить в скобки значение, к которому применяется .*
, если только это не простое имя таблицы. Например, если myfunc()
— функция, возвращающая составной тип со столбцами a
, b
и c
, то эти два запроса выдадут одинаковый результат:
SELECT (myfunc(x)).* FROM some_table; SELECT (myfunc(x)).a, (myfunc(x)).b, (myfunc(x)).c FROM some_table;
Подсказка
Postgres Pro осуществляет развёртывание столбцов фактически переводя первую форму во вторую. Таким образом, в данном примере myfunc()
будет вызываться три раза для каждой строки и с одним, и с другим синтаксисом. Если это дорогостоящая функция, и вы хотите избежать лишних вызовов, можно использовать такой запрос:
SELECT m.* FROM some_table, LATERAL myfunc(x) AS m;
Размещение вызова функции в элементе FROM
LATERAL
гарантирует, что она будет вызываться для строки не более одного раза. Конструкция m.*
так же разворачивается в m.a, m.b, m.c
, но теперь эти переменные просто ссылаются на выходные значения FROM
. (Ключевое слово LATERAL
здесь является необязательным, но мы добавили его, чтобы подчеркнуть, что функция получает x
из some_table
.)
Запись составное_значение
.*
приводит к такому развёртыванию столбцов, когда она фигурирует на верхнем уровне выходного списка SELECT
, в списке RETURNING
команд INSERT
/UPDATE
/DELETE
, в предложении VALUES
или в конструкторе строки. Во всех других контекстах (включая вложенные в одну из этих конструкций), добавление .*
к составному значению не меняет это значение, так как это воспринимается как «все столбцы» и поэтому выдаётся то же составное значение. Например, если функция somefunc()
принимает в качестве аргумента составное значение, эти запросы равносильны:
SELECT somefunc(c.*) FROM inventory_item c; SELECT somefunc(c) FROM inventory_item c;
В обоих случаях текущая строка таблицы inventory_item
передаётся функции как один аргумент с составным значением. И хотя дополнение .*
в этих случаях не играет роли, использовать его считается хорошим стилем, так как это ясно указывает на использование составного значения. В частности анализатор запроса воспримет c
в записи c.*
как ссылку на имя или псевдоним таблицы, а не имя столбца, что избавляет от неоднозначности; тогда как без .*
неясно, означает ли c
имя таблицы или имя столбца, и на самом деле при наличии столбца с именем c
будет выбрано второе прочтение.
Эту концепцию демонстрирует и следующий пример, все запросы в котором действуют одинаково:
SELECT * FROM inventory_item c ORDER BY c; SELECT * FROM inventory_item c ORDER BY c.*; SELECT * FROM inventory_item c ORDER BY ROW(c.*);
Все эти предложения ORDER BY
обращаются к составному значению строки, вследствие чего строки сортируются по правилам, описанным в Подразделе 9.24.6. Однако если в inventory_item
содержится столбец с именем c
, первый запрос будет отличаться от других, так как в нём выполнится сортировка только по данному столбцу. С показанными выше именами столбцов предыдущим запросам также равнозначны следующие:
SELECT * FROM inventory_item c ORDER BY ROW(c.name, c.supplier_id, c.price); SELECT * FROM inventory_item c ORDER BY (c.name, c.supplier_id, c.price);
(В последнем случае используется конструктор строки, в котором опущено ключевое слово ROW
.)
Другая особенность синтаксиса, связанная с составными значениями, состоит в том, что мы можем использовать функциональную запись для извлечения поля составного значения. Это легко можно объяснить тем, что записи
и поле
(таблица
)
взаимозаменяемы. Например, следующие запросы равнозначны: таблица
.поле
SELECT c.name FROM inventory_item c WHERE c.price > 1000; SELECT name(c) FROM inventory_item c WHERE price(c) > 1000;
Более того, если у нас есть функция, принимающая один аргумент составного типа, мы можем вызвать её в любой записи. Все эти запросы равносильны:
SELECT somefunc(c) FROM inventory_item c; SELECT somefunc(c.*) FROM inventory_item c; SELECT c.somefunc FROM inventory_item c;
Эта равнозначность записи с полем и функциональной записи позволяет использовать с составными типами функции, реализующие «вычисляемые поля». При этом приложению, использующему последний из предыдущих запросов, не нужно знать, что фактически somefunc
— не настоящий столбец таблицы.
Подсказка
Учитывая такое поведение, будет неразумно давать функции, принимающей один аргумент составного типа, то же имя, что и одному из полей данного составного типа. В случае неоднозначности прочтение имени поля будет выбрано при использовании синтаксиса обращения к полю, а прочтение имени функции — если используется синтаксис вызова функции. Однако в PostgreSQL до 11 версии всегда выбиралось прочтение имени поля, если только синтаксис вызова не подталкивал к прочтению имени функции. Чтобы принудительно выбрать прочтение имени функции, в предыдущих версиях надо было дополнить это имя схемой, то есть написать
.схема
.функция
(составное_значение
)
8.16.6. Синтаксис вводимых и выводимых значений составного типа
Внешнее текстовое представление составного значения состоит из записи элементов, интерпретируемых по правилам ввода/вывода для соответствующих типов полей, и оформления структуры составного типа. Оформление состоит из круглых скобок ((
и )
) окружающих всё значение, и запятых (,
) между его элементами. Пробельные символы вне скобок игнорируются, но внутри они считаются частью соответствующего элемента и могут учитываться или не учитываться в зависимости от правил преобразования вводимых данных для типа этого элемента. Например, в записи:
'( 42)'
пробелы будут игнорироваться, если соответствующее поле имеет целочисленный тип, но не текстовый.
Как было показано ранее, записывая составное значение, любой его элемент можно заключить в кавычки. Это нужно делать, если при разборе этого значения без кавычек возможна неоднозначность. Например, в кавычки нужно заключать элементы, содержащие скобки, кавычки, запятую или обратную косую черту. Чтобы включить в поле составного значения, заключённое в кавычки, такие символы, как кавычки или обратная косая черта, перед ними нужно добавить обратную косую черту. (Кроме того, продублированные кавычки в значении поля, заключённого в кавычки, воспринимаются как одинарные, подобно апострофам в строках SQL.) С другой стороны, можно обойтись без кавычек, защитив все символы в данных, которые могут быть восприняты как часть синтаксиса составного значения, с помощью спецпоследовательностей.
Значение NULL в этой записи представляется пустым местом (когда между запятыми или скобками нет никаких символов). Чтобы ввести именно пустую строку, а не NULL, нужно написать ""
.
Функция вывода составного значения заключает значения полей в кавычки, если они представляют собой пустые строки, либо содержат скобки, запятые, кавычки или обратную косую черту, либо состоят из одних пробелов. (В последнем случае можно обойтись без кавычек, но они добавляются для удобочитаемости.) Кавычки и обратная косая черта, заключённые в значения полей, при выводе дублируются.
Примечание
Помните, что написанная SQL-команда прежде всего интерпретируется как текстовая строка, а затем как составное значение. Вследствие этого число символов обратной косой черты удваивается (если используются спецпоследовательности). Например, чтобы ввести в поле составного столбца значение типа text
с обратной косой чертой и кавычками, команду нужно будет записать так:
INSERT ... VALUES ('("\"\\")');
Сначала обработчик спецпоследовательностей удаляет один уровень обратной косой черты, так что анализатор составного значения получает на вход ("\"\\")
. В свою очередь, он передаёт эту строку процедуре ввода значения типа text
, где она преобразуются в "\
. (Если бы мы работали с типом данных, процедура ввода которого также интерпретирует обратную косую черту особым образом, например bytea
, нам могло бы понадобиться уже восемь таких символов, чтобы сохранить этот символ в поле составного значения.) Во избежание такого дублирования спецсимволов строки можно заключать в доллары (см. Подраздел 4.1.2.4).
Подсказка
Записывать составные значения в командах SQL часто бывает удобнее с помощью конструктора ROW
. В ROW
отдельные значения элементов записываются так же, как если бы они не были членами составного выражения.
CLUSTER
CLUSTER — cluster a table according to an index
Synopsis
CLUSTER [ (option
[, ...] ) ] [table_name
[ USINGindex_name
] ] whereoption
can be one of: VERBOSE [boolean
]
Description
CLUSTER
instructs Postgres Pro to cluster the table specified by table_name
based on the index specified by index_name
. The index must already have been defined on table_name
.
When a table is clustered, it is physically reordered based on the index information. Clustering is a one-time operation: when the table is subsequently updated, the changes are not clustered. That is, no attempt is made to store new or updated rows according to their index order. (If one wishes, one can periodically recluster by issuing the command again. Also, setting the table's fillfactor
storage parameter to less than 100% can aid in preserving cluster ordering during updates, since updated rows are kept on the same page if enough space is available there.)
When a table is clustered, Postgres Pro remembers which index it was clustered by. The form CLUSTER
reclusters the table using the same index as before. You can also use the table_name
CLUSTER
or SET WITHOUT CLUSTER
forms of ALTER TABLE
to set the index to be used for future cluster operations, or to clear any previous setting.
CLUSTER
without a table_name
reclusters all the previously-clustered tables in the current database that the calling user has privileges for. This form of CLUSTER
cannot be executed inside a transaction block.
When a table is being clustered, an ACCESS EXCLUSIVE
lock is acquired on it. This prevents any other database operations (both reads and writes) from operating on the table until the CLUSTER
is finished.
Parameters
table_name
The name (possibly schema-qualified) of a table.
index_name
The name of an index.
VERBOSE
Prints a progress report as each table is clustered.
boolean
Specifies whether the selected option should be turned on or off. You can write
TRUE
,ON
, or1
to enable the option, andFALSE
,OFF
, or0
to disable it. Theboolean
value can also be omitted, in which caseTRUE
is assumed.
Notes
To cluster a table, one must have the MAINTAIN
privilege on the table.
In cases where you are accessing single rows randomly within a table, the actual order of the data in the table is unimportant. However, if you tend to access some data more than others, and there is an index that groups them together, you will benefit from using CLUSTER
. If you are requesting a range of indexed values from a table, or a single indexed value that has multiple rows that match, CLUSTER
will help because once the index identifies the table page for the first row that matches, all other rows that match are probably already on the same table page, and so you save disk accesses and speed up the query.
CLUSTER
can re-sort the table using either an index scan on the specified index, or (if the index is a b-tree) a sequential scan followed by sorting. It will attempt to choose the method that will be faster, based on planner cost parameters and available statistical information.
While CLUSTER
is running, the search_path is temporarily changed to pg_catalog, pg_temp
.
When an index scan is used, a temporary copy of the table is created that contains the table data in the index order. Temporary copies of each index on the table are created as well. Therefore, you need free space on disk at least equal to the sum of the table size and the index sizes.
When a sequential scan and sort is used, a temporary sort file is also created, so that the peak temporary space requirement is as much as double the table size, plus the index sizes. This method is often faster than the index scan method, but if the disk space requirement is intolerable, you can disable this choice by temporarily setting enable_sort to off
.
It is advisable to set maintenance_work_mem to a reasonably large value (but not more than the amount of RAM you can dedicate to the CLUSTER
operation) before clustering.
Because the planner records statistics about the ordering of tables, it is advisable to run ANALYZE
on the newly clustered table. Otherwise, the planner might make poor choices of query plans.
Because CLUSTER
remembers which indexes are clustered, one can cluster the tables one wants clustered manually the first time, then set up a periodic maintenance script that executes CLUSTER
without any parameters, so that the desired tables are periodically reclustered.
Each backend running CLUSTER
will report its progress in the pg_stat_progress_cluster
view. See Section 26.4.2 for details.
Clustering a partitioned table clusters each of its partitions using the partition of the specified partitioned index. When clustering a partitioned table, the index may not be omitted. CLUSTER
on a partitioned table cannot be executed inside a transaction block.
Examples
Cluster the table employees
on the basis of its index employees_ind
:
CLUSTER employees USING employees_ind;
Cluster the employees
table using the same index that was used before:
CLUSTER employees;
Cluster all tables in the database that have previously been clustered:
CLUSTER;
Compatibility
There is no CLUSTER
statement in the SQL standard.
The following syntax was used before PostgreSQL 17 and is still supported:
CLUSTER [ VERBOSE ] [table_name
[ USINGindex_name
] ]
The following syntax was used before PostgreSQL 8.3 and is still supported:
CLUSTERindex_name
ONtable_name