5.6. Системные столбцы #
В каждой таблице есть несколько системных столбцов, неявно определённых системой. Как следствие, их имена нельзя использовать в качестве имён пользовательских столбцов. (Заметьте, что это не зависит от того, является ли имя ключевым словом или нет; заключение имени в кавычки не поможет избежать этого ограничения.) Эти столбцы не должны вас беспокоить, вам лишь достаточно знать об их существовании.
tableoid#Идентификатор объекта для таблицы, содержащей строку. Этот столбец особенно полезен для запросов, имеющих дело с секционированными таблицами (см. Раздел 5.12) или иерархией наследования (см. Раздел 5.11), так как без него сложно определить, из какой таблицы выбрана строка. Связав
tableoidсо столбцомoidв таблицеpg_class, можно будет получить имя таблицы.xmin#Идентификатор (код) транзакции, добавившей строку этой версии. (Версия строки — это её индивидуальное состояние; при каждом изменении создаётся новая версия одной и той же логической строки.)
cmin#Номер команды (начиная с нуля) внутри транзакции, добавившей строку.
xmax#Идентификатор транзакции, удалившей строку, или 0 для неудалённой версии строки. Значение этого столбца может быть ненулевым и для видимой версии строки. Это обычно означает, что удаляющая транзакция ещё не была зафиксирована, или удаление было отменено.
cmax#Номер команды в удаляющей транзакции или ноль.
ctid#Физическое расположение данной версии строки в таблице. Заметьте, что хотя по
ctidможно очень быстро найти версию строки, значениеctidизменится при выполненииVACUUM FULL. Таким образом,ctidне следует применять в качестве идентификатора строки. Для идентификации логических строк следует использовать первичный ключ.
В Postgres Pro Enterprise идентификаторы транзакций реализованы как 64-битные счётчики, что позволяет предотвратить зацикливание идентификаторов. За подробностями обратитесь к Подразделу 24.1.5.
Идентификаторы команд 32-битные. Это создаёт жёсткий лимит на 232 (4 миллиарда) команд SQL в одной транзакции. На практике это не проблема — заметьте, что это лимит числа команд SQL, а не количества обрабатываемых строк. Кроме того, идентификатор получают только те команды, которые фактически изменяют содержимое базы данных.
5.6. System Columns #
Every table has several system columns that are implicitly defined by the system. Therefore, these names cannot be used as names of user-defined columns. (Note that these restrictions are separate from whether the name is a key word or not; quoting a name will not allow you to escape these restrictions.) You do not really need to be concerned about these columns; just know they exist.
tableoid#The OID of the table containing this row. This column is particularly handy for queries that select from partitioned tables (see Section 5.12) or inheritance hierarchies (see Section 5.11), since without it, it's difficult to tell which individual table a row came from. The
tableoidcan be joined against theoidcolumn ofpg_classto obtain the table name.xmin#The identity (transaction ID) of the inserting transaction for this row version. (A row version is an individual state of a row; each update of a row creates a new row version for the same logical row.)
cmin#The command identifier (starting at zero) within the inserting transaction.
xmax#The identity (transaction ID) of the deleting transaction, or zero for an undeleted row version. It is possible for this column to be nonzero in a visible row version. That usually indicates that the deleting transaction hasn't committed yet, or that an attempted deletion was rolled back.
cmax#The command identifier within the deleting transaction, or zero.
ctid#The physical location of the row version within its table. Note that although the
ctidcan be used to locate the row version very quickly, a row'sctidwill change if it is updated or moved byVACUUM FULL. Thereforectidshould not be used as a row identifier. A primary key should be used to identify logical rows.
In Postgres Pro Enterprise, transaction IDs are implemented as 64-bit counters to prevent transaction ID wraparound. For details, see Section 24.1.5.
Command identifiers are 32-bit quantities. This creates a hard limit of 232 (4 billion) SQL commands within a single transaction. In practice this limit is not a problem — note that the limit is on the number of SQL commands, not the number of rows processed. Also, only commands that actually modify the database contents will consume a command identifier.
