5.4. Системные столбцы
В каждой таблице есть несколько системных столбцов, неявно определённых системой. Как следствие, их имена нельзя использовать в качестве имён пользовательских столбцов. (Заметьте, что это не зависит от того, является ли имя ключевым словом или нет; заключение имени в кавычки не поможет избежать этого ограничения.) Эти столбцы не должны вас беспокоить, вам лишь достаточно знать об их существовании.
oidИдентификатор объекта (object ID) для строки. Этот столбец присутствует, только если таблица была создана с указанием
WITH OIDS, или если в момент её создания была установлена переменная конфигурации default_with_oids. Этот столбец имеет типoid(с тем же именем, что и сам столбец); подробнее об этом типе см. Раздел 8.19.tableoidИдентификатор объекта для таблицы, содержащей строку. Этот столбец особенно полезен для запросов, имеющих дело с иерархией наследования (см. Раздел 5.9), так как без него сложно определить, из какой таблицы выбрана строка. Связав
tableoidсо столбцомoidв таблицеpg_class, можно будет получить имя таблицы.xminИдентификатор (код) транзакции, добавившей строку этой версии. (Версия строки — это её индивидуальное состояние; при каждом изменении создаётся новая версия одной и той же логической строки.)
cminНомер команды (начиная с нуля) внутри транзакции, добавившей строку.
xmaxИдентификатор транзакции, удалившей строку, или 0 для неудалённой версии строки. Значение этого столбца может быть ненулевым и для видимой версии строки. Это обычно означает, что удаляющая транзакция ещё не была зафиксирована, или удаление было отменено.
cmaxНомер команды в удаляющей транзакции или ноль.
ctidФизическое расположение данной версии строки в таблице. Заметьте, что хотя по
ctidможно очень быстро найти версию строки, значениеctidизменится при выполненииVACUUM FULL. Таким образом,ctidнельзя применять в качестве долгосрочного идентификатора строки. Для идентификации логических строк лучше использовать OID или даже дополнительный последовательный номер.
Коды OID представляют собой 32-битные значения и выбираются из единого для всей СУБД счётчика. В больших или долгоживущих базах данных этот счётчик может пойти по кругу. Таким образом, не рекомендуется рассчитывать на уникальность OID, если только вы не обеспечите её дополнительно. Если вам нужно идентифицировать строки таблицы, настоятельно рекомендуется использовать последовательности. Однако можно использовать и коды OID, при выполнении следующих условий:
Когда для идентификации строк таблиц применяется OID, в каждой такой таблице должно создаваться ограничение уникальности для столбца OID. Когда такое ограничение уникальности (или уникальный индекс) существует, система позаботится о том, чтобы OID новой строки не совпал с уже существующими. (Конечно, это возможно, только если в таблице меньше 232 (4 миллиардов) строк, а на практике таблицы должны быть гораздо меньше, иначе может пострадать производительность системы.)
Никогда не следует рассчитывать, что OID будут уникальны среди всех таблиц; в качестве глобального идентификатора в рамках базы данных используйте комбинацию
tableoidи OID строки.Конечно, все эти таблицы должны быть созданы с указанием
WITH OIDS. В PostgreSQL 8.1 и новее по умолчанию подразумеваетсяWITHOUT OIDS.
В Postgres Pro Enterprise идентификаторы транзакций реализованы как 64-битные счётчики, что позволяет предотвратить зацикливание идентификаторов. За подробностями обратитесь к Подразделу 24.1.5.
Идентификаторы команд 32-битные. Это создаёт жёсткий лимит на 232 (4 миллиарда) команд SQL в одной транзакции. На практике это не проблема — заметьте, что это лимит числа команд SQL, а не количества обрабатываемых строк. Кроме того, идентификатор получают только те команды, которые фактически изменяют содержимое базы данных.
5.4. 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.
oidThe object identifier (object ID) of a row. This column is only present if the table was created using
WITH OIDS, or if the default_with_oids configuration variable was set at the time. This column is of typeoid(same name as the column); see Section 8.19 for more information about the type.tableoidThe OID of the table containing this row. This column is particularly handy for queries that select from inheritance hierarchies (see Section 5.9), 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.xminThe 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.)
cminThe command identifier (starting at zero) within the inserting transaction.
xmaxThe 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.
cmaxThe command identifier within the deleting transaction, or zero.
ctidThe 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. Thereforectidis useless as a long-term row identifier. The OID, or even better a user-defined serial number, should be used to identify logical rows.
OIDs are 32-bit quantities and are assigned from a single cluster-wide counter. In a large or long-lived database, it is possible for the counter to wrap around. Hence, it is bad practice to assume that OIDs are unique, unless you take steps to ensure that this is the case. If you need to identify the rows in a table, using a sequence generator is strongly recommended. However, OIDs can be used as well, provided that a few additional precautions are taken:
A unique constraint should be created on the OID column of each table for which the OID will be used to identify rows. When such a unique constraint (or unique index) exists, the system takes care not to generate an OID matching an already-existing row. (Of course, this is only possible if the table contains fewer than 232 (4 billion) rows, and in practice the table size had better be much less than that, or performance might suffer.)
OIDs should never be assumed to be unique across tables; use the combination of
tableoidand row OID if you need a database-wide identifier.Of course, the tables in question must be created
WITH OIDS. As of PostgreSQL 8.1,WITHOUT OIDSis the default.
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.
