{"kind": "oid", "major": "18", "rows": [{"slug": "oid", "name": "oid", "name_zh": "oid", "category": "Object identifiers", "summary": "numeric object identifier.", "aliases": [], "versions": {"10": {"facts": [{"label": "Referenced catalog", "value": "any"}, {"label": "Description", "value": "numeric object identifier"}, {"label": "Input example", "value": "564182"}], "related": [{"url": "/docs/10/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["numeric object identifier."]}, "11": {"facts": [{"label": "Referenced catalog", "value": "any"}, {"label": "Description", "value": "numeric object identifier"}, {"label": "Input example", "value": "564182"}], "related": [{"url": "/docs/11/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["numeric object identifier."]}, "12": {"facts": [{"label": "Referenced catalog", "value": "any"}, {"label": "Description", "value": "numeric object identifier"}, {"label": "Input example", "value": "564182"}], "related": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["numeric object identifier."]}, "13": {"facts": [{"label": "Referenced catalog", "value": "any"}, {"label": "Description", "value": "numeric object identifier"}, {"label": "Input example", "value": "564182"}], "related": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["numeric object identifier."]}, "14": {"facts": [{"label": "Referenced catalog", "value": "any"}, {"label": "Description", "value": "numeric object identifier"}, {"label": "Input example", "value": "564182"}], "related": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/14/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.70"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.70 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["numeric object identifier."]}, "15": {"facts": [{"label": "Referenced catalog", "value": "any"}, {"label": "Description", "value": "numeric object identifier"}, {"label": "Input example", "value": "564182"}], "related": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/15/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.71"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.71 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["numeric object identifier."]}, "16": {"facts": [{"label": "Referenced catalog", "value": "any"}, {"label": "Description", "value": "numeric object identifier"}, {"label": "Input example", "value": "564182"}], "related": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/16/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.72"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.72 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["numeric object identifier."]}, "17": {"facts": [{"label": "Referenced catalog", "value": "any"}, {"label": "Description", "value": "numeric object identifier"}, {"label": "Input example", "value": "564182"}], "related": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/17/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.74"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.74 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["numeric object identifier."]}, "18": {"facts": [{"label": "Referenced catalog", "value": "any"}, {"label": "Description", "value": "numeric object identifier"}, {"label": "Input example", "value": "564182"}], "related": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/18/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.76"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.76 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["numeric object identifier."]}, "19": {"facts": [{"label": "Referenced catalog", "value": "any"}, {"label": "Description", "value": "numeric object identifier"}, {"label": "Input example", "value": "564182"}], "related": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/19/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["numeric object identifier."]}, "20": {"facts": [{"label": "Referenced catalog", "value": "any"}, {"label": "Description", "value": "numeric object identifier"}, {"label": "Input example", "value": "564182"}], "related": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL devel online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["numeric object identifier."]}}, "content_hash": "28c115120c78f8e191dfba7c7677af81e28fcd54a511afa62fc95dbce84dfbea", "imported_at": "2026-09-27T09:57:59.072", "url": "/wiki/oid/oid/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/oid/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/oid/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/oid/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/oid/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/oid/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/oid/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/oid/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/oid/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/oid/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/oid/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/oid/?v=20"}], "present": true}, {"slug": "oid8", "name": "oid8", "name_zh": "oid8", "category": "Object identifiers", "summary": "Not recorded in the selected version.", "aliases": [], "versions": {"19": {"facts": [], "related": [], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 19 online manual"}], "sections": [], "description": ["In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}, "20": {"facts": [], "related": [], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL devel online manual"}], "sections": [], "description": ["In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}}, "content_hash": "493a41b87c064199352b59f7a3361fc0545db0361991fb00e9f2c7588b710241", "imported_at": "2026-09-27T09:57:59.077", "url": "/wiki/oid/oid8/?v=18", "cells": [{"major": "10", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 10.23 \u00b7 Not recorded in this version", "url": "/wiki/oid/oid8/?v=10"}, {"major": "11", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 11.22 \u00b7 Not recorded in this version", "url": "/wiki/oid/oid8/?v=11"}, {"major": "12", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 12.22 \u00b7 Not recorded in this version", "url": "/wiki/oid/oid8/?v=12"}, {"major": "13", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 13.23 \u00b7 Not recorded in this version", "url": "/wiki/oid/oid8/?v=13"}, {"major": "14", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 14.24 \u00b7 Not recorded in this version", "url": "/wiki/oid/oid8/?v=14"}, {"major": "15", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 15.19 \u00b7 Not recorded in this version", "url": "/wiki/oid/oid8/?v=15"}, {"major": "16", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 16.15 \u00b7 Not recorded in this version", "url": "/wiki/oid/oid8/?v=16"}, {"major": "17", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 17.11 \u00b7 Not recorded in this version", "url": "/wiki/oid/oid8/?v=17"}, {"major": "18", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 18.6 \u00b7 Not recorded in this version", "url": "/wiki/oid/oid8/?v=18"}, {"major": "19", "state": "added", "label": "First recorded in this sample", "title": "PostgreSQL 19beta4 \u00b7 First recorded in this sample", "url": "/wiki/oid/oid8/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/oid8/?v=20"}], "present": false}, {"slug": "regclass", "name": "regclass", "name_zh": "regclass", "category": "Object name aliases", "summary": "relation name.", "aliases": [], "versions": {"10": {"facts": [{"label": "Referenced catalog", "value": "pg_class"}, {"label": "Description", "value": "relation name"}, {"label": "Input example", "value": "pg_type"}], "related": [{"url": "/docs/catalog/pg_class/?v=10", "label": "pg_class catalog"}, {"url": "/docs/10/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["relation name."]}, "11": {"facts": [{"label": "Referenced catalog", "value": "pg_class"}, {"label": "Description", "value": "relation name"}, {"label": "Input example", "value": "pg_type"}], "related": [{"url": "/docs/catalog/pg_class/?v=11", "label": "pg_class catalog"}, {"url": "/docs/11/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["relation name."]}, "12": {"facts": [{"label": "Referenced catalog", "value": "pg_class"}, {"label": "Description", "value": "relation name"}, {"label": "Input example", "value": "pg_type"}], "related": [{"url": "/docs/catalog/pg_class/?v=12", "label": "pg_class catalog"}, {"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["relation name."]}, "13": {"facts": [{"label": "Referenced catalog", "value": "pg_class"}, {"label": "Description", "value": "relation name"}, {"label": "Input example", "value": "pg_type"}], "related": [{"url": "/docs/catalog/pg_class/?v=13", "label": "pg_class catalog"}, {"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["relation name."]}, "14": {"facts": [{"label": "Referenced catalog", "value": "pg_class"}, {"label": "Description", "value": "relation name"}, {"label": "Input example", "value": "pg_type"}], "related": [{"url": "/docs/catalog/pg_class/?v=14", "label": "pg_class catalog"}, {"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/14/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.70"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.70 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["relation name."]}, "15": {"facts": [{"label": "Referenced catalog", "value": "pg_class"}, {"label": "Description", "value": "relation name"}, {"label": "Input example", "value": "pg_type"}], "related": [{"url": "/docs/catalog/pg_class/?v=15", "label": "pg_class catalog"}, {"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/15/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.71"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.71 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["relation name."]}, "16": {"facts": [{"label": "Referenced catalog", "value": "pg_class"}, {"label": "Description", "value": "relation name"}, {"label": "Input example", "value": "pg_type"}], "related": [{"url": "/docs/catalog/pg_class/?v=16", "label": "pg_class catalog"}, {"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/16/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.72"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.72 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["relation name."]}, "17": {"facts": [{"label": "Referenced catalog", "value": "pg_class"}, {"label": "Description", "value": "relation name"}, {"label": "Input example", "value": "pg_type"}], "related": [{"url": "/docs/catalog/pg_class/?v=17", "label": "pg_class catalog"}, {"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/17/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.74"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.74 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["relation name."]}, "18": {"facts": [{"label": "Referenced catalog", "value": "pg_class"}, {"label": "Description", "value": "relation name"}, {"label": "Input example", "value": "pg_type"}], "related": [{"url": "/docs/catalog/pg_class/?v=18", "label": "pg_class catalog"}, {"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/18/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.76"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.76 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["relation name."]}, "19": {"facts": [{"label": "Referenced catalog", "value": "pg_class"}, {"label": "Description", "value": "relation name"}, {"label": "Input example", "value": "pg_type"}], "related": [{"url": "/docs/catalog/pg_class/?v=19", "label": "pg_class catalog"}, {"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/19/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["relation name."]}, "20": {"facts": [{"label": "Referenced catalog", "value": "pg_class"}, {"label": "Description", "value": "relation name"}, {"label": "Input example", "value": "pg_type"}], "related": [{"url": "/docs/catalog/pg_class/?v=20", "label": "pg_class catalog"}, {"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL devel online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["relation name."]}}, "content_hash": "34f66e5e84a30c7d4fa4e889ef52c70a2e4fa359dd4baeed383e7dcaa60b0db6", "imported_at": "2026-09-27T09:57:59.080", "url": "/wiki/oid/regclass/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/regclass/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/regclass/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/regclass/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/regclass/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/regclass/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/regclass/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/regclass/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/regclass/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/regclass/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/regclass/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/regclass/?v=20"}], "present": true}, {"slug": "regcollation", "name": "regcollation", "name_zh": "regcollation", "category": "Object name aliases", "summary": "collation name.", "aliases": [], "versions": {"13": {"facts": [{"label": "Referenced catalog", "value": "pg_collation"}, {"label": "Description", "value": "collation name"}, {"label": "Input example", "value": "\"POSIX\""}], "related": [{"url": "/docs/catalog/pg_collation/?v=13", "label": "pg_collation catalog"}, {"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["collation name."]}, "14": {"facts": [{"label": "Referenced catalog", "value": "pg_collation"}, {"label": "Description", "value": "collation name"}, {"label": "Input example", "value": "\"POSIX\""}], "related": [{"url": "/docs/catalog/pg_collation/?v=14", "label": "pg_collation catalog"}, {"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/14/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.70"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.70 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["collation name."]}, "15": {"facts": [{"label": "Referenced catalog", "value": "pg_collation"}, {"label": "Description", "value": "collation name"}, {"label": "Input example", "value": "\"POSIX\""}], "related": [{"url": "/docs/catalog/pg_collation/?v=15", "label": "pg_collation catalog"}, {"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/15/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.71"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.71 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["collation name."]}, "16": {"facts": [{"label": "Referenced catalog", "value": "pg_collation"}, {"label": "Description", "value": "collation name"}, {"label": "Input example", "value": "\"POSIX\""}], "related": [{"url": "/docs/catalog/pg_collation/?v=16", "label": "pg_collation catalog"}, {"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/16/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.72"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.72 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["collation name."]}, "17": {"facts": [{"label": "Referenced catalog", "value": "pg_collation"}, {"label": "Description", "value": "collation name"}, {"label": "Input example", "value": "\"POSIX\""}], "related": [{"url": "/docs/catalog/pg_collation/?v=17", "label": "pg_collation catalog"}, {"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/17/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.74"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.74 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["collation name."]}, "18": {"facts": [{"label": "Referenced catalog", "value": "pg_collation"}, {"label": "Description", "value": "collation name"}, {"label": "Input example", "value": "\"POSIX\""}], "related": [{"url": "/docs/catalog/pg_collation/?v=18", "label": "pg_collation catalog"}, {"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/18/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.76"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.76 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["collation name."]}, "19": {"facts": [{"label": "Referenced catalog", "value": "pg_collation"}, {"label": "Description", "value": "collation name"}, {"label": "Input example", "value": "\"POSIX\""}], "related": [{"url": "/docs/catalog/pg_collation/?v=19", "label": "pg_collation catalog"}, {"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/19/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["collation name."]}, "20": {"facts": [{"label": "Referenced catalog", "value": "pg_collation"}, {"label": "Description", "value": "collation name"}, {"label": "Input example", "value": "\"POSIX\""}], "related": [{"url": "/docs/catalog/pg_collation/?v=20", "label": "pg_collation catalog"}, {"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL devel online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["collation name."]}}, "content_hash": "b2edde4d071988af1715209da264eabe62e705699306a13ebff92954687c474a", "imported_at": "2026-09-27T09:57:59.084", "url": "/wiki/oid/regcollation/?v=18", "cells": [{"major": "10", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 10.23 \u00b7 Not recorded in this version", "url": "/wiki/oid/regcollation/?v=10"}, {"major": "11", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 11.22 \u00b7 Not recorded in this version", "url": "/wiki/oid/regcollation/?v=11"}, {"major": "12", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 12.22 \u00b7 Not recorded in this version", "url": "/wiki/oid/regcollation/?v=12"}, {"major": "13", "state": "added", "label": "First recorded in this sample", "title": "PostgreSQL 13.23 \u00b7 First recorded in this sample", "url": "/wiki/oid/regcollation/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/regcollation/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/regcollation/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/regcollation/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/regcollation/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/regcollation/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/regcollation/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/regcollation/?v=20"}], "present": true}, {"slug": "regconfig", "name": "regconfig", "name_zh": "regconfig", "category": "Object name aliases", "summary": "text search configuration.", "aliases": [], "versions": {"10": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_config"}, {"label": "Description", "value": "text search configuration"}, {"label": "Input example", "value": "english"}], "related": [{"url": "/docs/catalog/pg_ts_config/?v=10", "label": "pg_ts_config catalog"}, {"url": "/docs/10/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["text search configuration."]}, "11": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_config"}, {"label": "Description", "value": "text search configuration"}, {"label": "Input example", "value": "english"}], "related": [{"url": "/docs/catalog/pg_ts_config/?v=11", "label": "pg_ts_config catalog"}, {"url": "/docs/11/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["text search configuration."]}, "12": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_config"}, {"label": "Description", "value": "text search configuration"}, {"label": "Input example", "value": "english"}], "related": [{"url": "/docs/catalog/pg_ts_config/?v=12", "label": "pg_ts_config catalog"}, {"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["text search configuration."]}, "13": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_config"}, {"label": "Description", "value": "text search configuration"}, {"label": "Input example", "value": "english"}], "related": [{"url": "/docs/catalog/pg_ts_config/?v=13", "label": "pg_ts_config catalog"}, {"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["text search configuration."]}, "14": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_config"}, {"label": "Description", "value": "text search configuration"}, {"label": "Input example", "value": "english"}], "related": [{"url": "/docs/catalog/pg_ts_config/?v=14", "label": "pg_ts_config catalog"}, {"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/14/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.70"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.70 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search configuration."]}, "15": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_config"}, {"label": "Description", "value": "text search configuration"}, {"label": "Input example", "value": "english"}], "related": [{"url": "/docs/catalog/pg_ts_config/?v=15", "label": "pg_ts_config catalog"}, {"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/15/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.71"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.71 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search configuration."]}, "16": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_config"}, {"label": "Description", "value": "text search configuration"}, {"label": "Input example", "value": "english"}], "related": [{"url": "/docs/catalog/pg_ts_config/?v=16", "label": "pg_ts_config catalog"}, {"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/16/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.72"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.72 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search configuration."]}, "17": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_config"}, {"label": "Description", "value": "text search configuration"}, {"label": "Input example", "value": "english"}], "related": [{"url": "/docs/catalog/pg_ts_config/?v=17", "label": "pg_ts_config catalog"}, {"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/17/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.74"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.74 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search configuration."]}, "18": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_config"}, {"label": "Description", "value": "text search configuration"}, {"label": "Input example", "value": "english"}], "related": [{"url": "/docs/catalog/pg_ts_config/?v=18", "label": "pg_ts_config catalog"}, {"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/18/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.76"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.76 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search configuration."]}, "19": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_config"}, {"label": "Description", "value": "text search configuration"}, {"label": "Input example", "value": "english"}], "related": [{"url": "/docs/catalog/pg_ts_config/?v=19", "label": "pg_ts_config catalog"}, {"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/19/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search configuration."]}, "20": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_config"}, {"label": "Description", "value": "text search configuration"}, {"label": "Input example", "value": "english"}], "related": [{"url": "/docs/catalog/pg_ts_config/?v=20", "label": "pg_ts_config catalog"}, {"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL devel online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search configuration."]}}, "content_hash": "dffdfce6d7e3c4c859f97f0f2dbf3c1916414e4c5f42635bab72f39b84a4c8f4", "imported_at": "2026-09-27T09:57:59.087", "url": "/wiki/oid/regconfig/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/regconfig/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/regconfig/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/regconfig/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/regconfig/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/regconfig/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/regconfig/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/regconfig/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/regconfig/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/regconfig/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/regconfig/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/regconfig/?v=20"}], "present": true}, {"slug": "regdatabase", "name": "regdatabase", "name_zh": "regdatabase", "category": "Object name aliases", "summary": "Not recorded in the selected version.", "aliases": [], "versions": {"19": {"facts": [{"label": "Referenced catalog", "value": "pg_database"}, {"label": "Description", "value": "database name"}, {"label": "Input example", "value": "template1"}], "related": [{"url": "/docs/catalog/pg_database/?v=19", "label": "pg_database catalog"}, {"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/19/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["database name."]}, "20": {"facts": [{"label": "Referenced catalog", "value": "pg_database"}, {"label": "Description", "value": "database name"}, {"label": "Input example", "value": "template1"}], "related": [{"url": "/docs/catalog/pg_database/?v=20", "label": "pg_database catalog"}, {"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL devel online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["database name."]}}, "content_hash": "9fcae6d79de6a4e5510bf260edd157110f6435320d2d288492dc2e967ae8a9c9", "imported_at": "2026-09-27T09:57:59.091", "url": "/wiki/oid/regdatabase/?v=18", "cells": [{"major": "10", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 10.23 \u00b7 Not recorded in this version", "url": "/wiki/oid/regdatabase/?v=10"}, {"major": "11", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 11.22 \u00b7 Not recorded in this version", "url": "/wiki/oid/regdatabase/?v=11"}, {"major": "12", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 12.22 \u00b7 Not recorded in this version", "url": "/wiki/oid/regdatabase/?v=12"}, {"major": "13", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 13.23 \u00b7 Not recorded in this version", "url": "/wiki/oid/regdatabase/?v=13"}, {"major": "14", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 14.24 \u00b7 Not recorded in this version", "url": "/wiki/oid/regdatabase/?v=14"}, {"major": "15", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 15.19 \u00b7 Not recorded in this version", "url": "/wiki/oid/regdatabase/?v=15"}, {"major": "16", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 16.15 \u00b7 Not recorded in this version", "url": "/wiki/oid/regdatabase/?v=16"}, {"major": "17", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 17.11 \u00b7 Not recorded in this version", "url": "/wiki/oid/regdatabase/?v=17"}, {"major": "18", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 18.6 \u00b7 Not recorded in this version", "url": "/wiki/oid/regdatabase/?v=18"}, {"major": "19", "state": "added", "label": "First recorded in this sample", "title": "PostgreSQL 19beta4 \u00b7 First recorded in this sample", "url": "/wiki/oid/regdatabase/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/regdatabase/?v=20"}], "present": false}, {"slug": "regdictionary", "name": "regdictionary", "name_zh": "regdictionary", "category": "Object name aliases", "summary": "text search dictionary.", "aliases": [], "versions": {"10": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_dict"}, {"label": "Description", "value": "text search dictionary"}, {"label": "Input example", "value": "simple"}], "related": [{"url": "/docs/catalog/pg_ts_dict/?v=10", "label": "pg_ts_dict catalog"}, {"url": "/docs/10/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["text search dictionary."]}, "11": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_dict"}, {"label": "Description", "value": "text search dictionary"}, {"label": "Input example", "value": "simple"}], "related": [{"url": "/docs/catalog/pg_ts_dict/?v=11", "label": "pg_ts_dict catalog"}, {"url": "/docs/11/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["text search dictionary."]}, "12": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_dict"}, {"label": "Description", "value": "text search dictionary"}, {"label": "Input example", "value": "simple"}], "related": [{"url": "/docs/catalog/pg_ts_dict/?v=12", "label": "pg_ts_dict catalog"}, {"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["text search dictionary."]}, "13": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_dict"}, {"label": "Description", "value": "text search dictionary"}, {"label": "Input example", "value": "simple"}], "related": [{"url": "/docs/catalog/pg_ts_dict/?v=13", "label": "pg_ts_dict catalog"}, {"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["text search dictionary."]}, "14": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_dict"}, {"label": "Description", "value": "text search dictionary"}, {"label": "Input example", "value": "simple"}], "related": [{"url": "/docs/catalog/pg_ts_dict/?v=14", "label": "pg_ts_dict catalog"}, {"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/14/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.70"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.70 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search dictionary."]}, "15": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_dict"}, {"label": "Description", "value": "text search dictionary"}, {"label": "Input example", "value": "simple"}], "related": [{"url": "/docs/catalog/pg_ts_dict/?v=15", "label": "pg_ts_dict catalog"}, {"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/15/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.71"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.71 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search dictionary."]}, "16": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_dict"}, {"label": "Description", "value": "text search dictionary"}, {"label": "Input example", "value": "simple"}], "related": [{"url": "/docs/catalog/pg_ts_dict/?v=16", "label": "pg_ts_dict catalog"}, {"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/16/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.72"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.72 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search dictionary."]}, "17": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_dict"}, {"label": "Description", "value": "text search dictionary"}, {"label": "Input example", "value": "simple"}], "related": [{"url": "/docs/catalog/pg_ts_dict/?v=17", "label": "pg_ts_dict catalog"}, {"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/17/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.74"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.74 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search dictionary."]}, "18": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_dict"}, {"label": "Description", "value": "text search dictionary"}, {"label": "Input example", "value": "simple"}], "related": [{"url": "/docs/catalog/pg_ts_dict/?v=18", "label": "pg_ts_dict catalog"}, {"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/18/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.76"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.76 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search dictionary."]}, "19": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_dict"}, {"label": "Description", "value": "text search dictionary"}, {"label": "Input example", "value": "simple"}], "related": [{"url": "/docs/catalog/pg_ts_dict/?v=19", "label": "pg_ts_dict catalog"}, {"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/19/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search dictionary."]}, "20": {"facts": [{"label": "Referenced catalog", "value": "pg_ts_dict"}, {"label": "Description", "value": "text search dictionary"}, {"label": "Input example", "value": "simple"}], "related": [{"url": "/docs/catalog/pg_ts_dict/?v=20", "label": "pg_ts_dict catalog"}, {"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL devel online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["text search dictionary."]}}, "content_hash": "68031fa00526976c347c9a54eec12ab624d816e23a3bd7b0c79ee5c3b557936f", "imported_at": "2026-09-27T09:57:59.092", "url": "/wiki/oid/regdictionary/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/regdictionary/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/regdictionary/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/regdictionary/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/regdictionary/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/regdictionary/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/regdictionary/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/regdictionary/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/regdictionary/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/regdictionary/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/regdictionary/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/regdictionary/?v=20"}], "present": true}, {"slug": "regnamespace", "name": "regnamespace", "name_zh": "regnamespace", "category": "Object name aliases", "summary": "namespace name.", "aliases": [], "versions": {"10": {"facts": [{"label": "Referenced catalog", "value": "pg_namespace"}, {"label": "Description", "value": "namespace name"}, {"label": "Input example", "value": "pg_catalog"}], "related": [{"url": "/docs/catalog/pg_namespace/?v=10", "label": "pg_namespace catalog"}, {"url": "/docs/10/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["namespace name."]}, "11": {"facts": [{"label": "Referenced catalog", "value": "pg_namespace"}, {"label": "Description", "value": "namespace name"}, {"label": "Input example", "value": "pg_catalog"}], "related": [{"url": "/docs/catalog/pg_namespace/?v=11", "label": "pg_namespace catalog"}, {"url": "/docs/11/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["namespace name."]}, "12": {"facts": [{"label": "Referenced catalog", "value": "pg_namespace"}, {"label": "Description", "value": "namespace name"}, {"label": "Input example", "value": "pg_catalog"}], "related": [{"url": "/docs/catalog/pg_namespace/?v=12", "label": "pg_namespace catalog"}, {"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["namespace name."]}, "13": {"facts": [{"label": "Referenced catalog", "value": "pg_namespace"}, {"label": "Description", "value": "namespace name"}, {"label": "Input example", "value": "pg_catalog"}], "related": [{"url": "/docs/catalog/pg_namespace/?v=13", "label": "pg_namespace catalog"}, {"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["namespace name."]}, "14": {"facts": [{"label": "Referenced catalog", "value": "pg_namespace"}, {"label": "Description", "value": "namespace name"}, {"label": "Input example", "value": "pg_catalog"}], "related": [{"url": "/docs/catalog/pg_namespace/?v=14", "label": "pg_namespace catalog"}, {"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/14/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.70"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.70 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["namespace name."]}, "15": {"facts": [{"label": "Referenced catalog", "value": "pg_namespace"}, {"label": "Description", "value": "namespace name"}, {"label": "Input example", "value": "pg_catalog"}], "related": [{"url": "/docs/catalog/pg_namespace/?v=15", "label": "pg_namespace catalog"}, {"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/15/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.71"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.71 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["namespace name."]}, "16": {"facts": [{"label": "Referenced catalog", "value": "pg_namespace"}, {"label": "Description", "value": "namespace name"}, {"label": "Input example", "value": "pg_catalog"}], "related": [{"url": "/docs/catalog/pg_namespace/?v=16", "label": "pg_namespace catalog"}, {"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/16/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.72"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.72 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["namespace name."]}, "17": {"facts": [{"label": "Referenced catalog", "value": "pg_namespace"}, {"label": "Description", "value": "namespace name"}, {"label": "Input example", "value": "pg_catalog"}], "related": [{"url": "/docs/catalog/pg_namespace/?v=17", "label": "pg_namespace catalog"}, {"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/17/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.74"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.74 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["namespace name."]}, "18": {"facts": [{"label": "Referenced catalog", "value": "pg_namespace"}, {"label": "Description", "value": "namespace name"}, {"label": "Input example", "value": "pg_catalog"}], "related": [{"url": "/docs/catalog/pg_namespace/?v=18", "label": "pg_namespace catalog"}, {"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/18/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.76"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.76 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["namespace name."]}, "19": {"facts": [{"label": "Referenced catalog", "value": "pg_namespace"}, {"label": "Description", "value": "namespace name"}, {"label": "Input example", "value": "pg_catalog"}], "related": [{"url": "/docs/catalog/pg_namespace/?v=19", "label": "pg_namespace catalog"}, {"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/19/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["namespace name."]}, "20": {"facts": [{"label": "Referenced catalog", "value": "pg_namespace"}, {"label": "Description", "value": "namespace name"}, {"label": "Input example", "value": "pg_catalog"}], "related": [{"url": "/docs/catalog/pg_namespace/?v=20", "label": "pg_namespace catalog"}, {"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL devel online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["namespace name."]}}, "content_hash": "7520b62ed1a816b93f58a843f994ff6663388137b59809e7caa6731e67d4c102", "imported_at": "2026-09-27T09:57:59.096", "url": "/wiki/oid/regnamespace/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/regnamespace/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/regnamespace/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/regnamespace/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/regnamespace/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/regnamespace/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/regnamespace/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/regnamespace/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/regnamespace/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/regnamespace/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/regnamespace/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/regnamespace/?v=20"}], "present": true}, {"slug": "regoper", "name": "regoper", "name_zh": "regoper", "category": "Object name aliases", "summary": "operator name.", "aliases": [], "versions": {"10": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator name"}, {"label": "Input example", "value": "+"}], "related": [{"url": "/docs/catalog/pg_operator/?v=10", "label": "pg_operator catalog"}, {"url": "/docs/10/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["operator name."]}, "11": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator name"}, {"label": "Input example", "value": "+"}], "related": [{"url": "/docs/catalog/pg_operator/?v=11", "label": "pg_operator catalog"}, {"url": "/docs/11/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["operator name."]}, "12": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator name"}, {"label": "Input example", "value": "+"}], "related": [{"url": "/docs/catalog/pg_operator/?v=12", "label": "pg_operator catalog"}, {"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["operator name."]}, "13": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator name"}, {"label": "Input example", "value": "+"}], "related": [{"url": "/docs/catalog/pg_operator/?v=13", "label": "pg_operator catalog"}, {"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["operator name."]}, "14": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator name"}, {"label": "Input example", "value": "+"}], "related": [{"url": "/docs/catalog/pg_operator/?v=14", "label": "pg_operator catalog"}, {"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/14/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.70"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.70 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator name."]}, "15": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator name"}, {"label": "Input example", "value": "+"}], "related": [{"url": "/docs/catalog/pg_operator/?v=15", "label": "pg_operator catalog"}, {"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/15/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.71"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.71 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator name."]}, "16": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator name"}, {"label": "Input example", "value": "+"}], "related": [{"url": "/docs/catalog/pg_operator/?v=16", "label": "pg_operator catalog"}, {"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/16/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.72"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.72 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator name."]}, "17": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator name"}, {"label": "Input example", "value": "+"}], "related": [{"url": "/docs/catalog/pg_operator/?v=17", "label": "pg_operator catalog"}, {"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/17/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.74"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.74 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator name."]}, "18": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator name"}, {"label": "Input example", "value": "+"}], "related": [{"url": "/docs/catalog/pg_operator/?v=18", "label": "pg_operator catalog"}, {"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/18/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.76"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.76 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator name."]}, "19": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator name"}, {"label": "Input example", "value": "+"}], "related": [{"url": "/docs/catalog/pg_operator/?v=19", "label": "pg_operator catalog"}, {"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/19/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator name."]}, "20": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator name"}, {"label": "Input example", "value": "+"}], "related": [{"url": "/docs/catalog/pg_operator/?v=20", "label": "pg_operator catalog"}, {"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL devel online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator name."]}}, "content_hash": "db69a28efee9349b7b3c5903eb5b3d05667465d84b6c12fcae60a19ead5293ba", "imported_at": "2026-09-27T09:57:59.100", "url": "/wiki/oid/regoper/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/regoper/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/regoper/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/regoper/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/regoper/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/regoper/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/regoper/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/regoper/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/regoper/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/regoper/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/regoper/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/regoper/?v=20"}], "present": true}, {"slug": "regoperator", "name": "regoperator", "name_zh": "regoperator", "category": "Object name aliases", "summary": "operator with argument types.", "aliases": [], "versions": {"10": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator with argument types"}, {"label": "Input example", "value": "*(integer,integer) or -(NONE,integer)"}], "related": [{"url": "/docs/catalog/pg_operator/?v=10", "label": "pg_operator catalog"}, {"url": "/docs/10/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["operator with argument types."]}, "11": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator with argument types"}, {"label": "Input example", "value": "*(integer,integer) or -(NONE,integer)"}], "related": [{"url": "/docs/catalog/pg_operator/?v=11", "label": "pg_operator catalog"}, {"url": "/docs/11/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["operator with argument types."]}, "12": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator with argument types"}, {"label": "Input example", "value": "*(integer,integer) or -(NONE,integer)"}], "related": [{"url": "/docs/catalog/pg_operator/?v=12", "label": "pg_operator catalog"}, {"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["operator with argument types."]}, "13": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator with argument types"}, {"label": "Input example", "value": "*(integer,integer) or -(NONE,integer)"}], "related": [{"url": "/docs/catalog/pg_operator/?v=13", "label": "pg_operator catalog"}, {"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["operator with argument types."]}, "14": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator with argument types"}, {"label": "Input example", "value": "*(integer,integer) or -(NONE,integer)"}], "related": [{"url": "/docs/catalog/pg_operator/?v=14", "label": "pg_operator catalog"}, {"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/14/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.70"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.70 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator with argument types."]}, "15": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator with argument types"}, {"label": "Input example", "value": "*(integer,integer) or -(NONE,integer)"}], "related": [{"url": "/docs/catalog/pg_operator/?v=15", "label": "pg_operator catalog"}, {"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/15/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.71"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.71 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator with argument types."]}, "16": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator with argument types"}, {"label": "Input example", "value": "*(integer,integer) or -(NONE,integer)"}], "related": [{"url": "/docs/catalog/pg_operator/?v=16", "label": "pg_operator catalog"}, {"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/16/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.72"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.72 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator with argument types."]}, "17": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator with argument types"}, {"label": "Input example", "value": "*(integer,integer) or -(NONE,integer)"}], "related": [{"url": "/docs/catalog/pg_operator/?v=17", "label": "pg_operator catalog"}, {"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/17/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.74"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.74 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator with argument types."]}, "18": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator with argument types"}, {"label": "Input example", "value": "*(integer,integer) or -(NONE,integer)"}], "related": [{"url": "/docs/catalog/pg_operator/?v=18", "label": "pg_operator catalog"}, {"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/18/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.76"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.76 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator with argument types."]}, "19": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator with argument types"}, {"label": "Input example", "value": "*(integer,integer) or -(NONE,integer)"}], "related": [{"url": "/docs/catalog/pg_operator/?v=19", "label": "pg_operator catalog"}, {"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/19/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator with argument types."]}, "20": {"facts": [{"label": "Referenced catalog", "value": "pg_operator"}, {"label": "Description", "value": "operator with argument types"}, {"label": "Input example", "value": "*(integer,integer) or -(NONE,integer)"}], "related": [{"url": "/docs/catalog/pg_operator/?v=20", "label": "pg_operator catalog"}, {"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL devel online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["operator with argument types."]}}, "content_hash": "2b6c00028259f298bbbb3491fdfe28e6f22174fe19be31b8b21ab9d522c20731", "imported_at": "2026-09-27T09:57:59.104", "url": "/wiki/oid/regoperator/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/regoperator/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/regoperator/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/regoperator/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/regoperator/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/regoperator/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/regoperator/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/regoperator/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/regoperator/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/regoperator/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/regoperator/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/regoperator/?v=20"}], "present": true}, {"slug": "regproc", "name": "regproc", "name_zh": "regproc", "category": "Object name aliases", "summary": "function name.", "aliases": [], "versions": {"10": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function name"}, {"label": "Input example", "value": "sum"}], "related": [{"url": "/docs/catalog/pg_proc/?v=10", "label": "pg_proc catalog"}, {"url": "/docs/10/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["function name."]}, "11": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function name"}, {"label": "Input example", "value": "sum"}], "related": [{"url": "/docs/catalog/pg_proc/?v=11", "label": "pg_proc catalog"}, {"url": "/docs/11/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["function name."]}, "12": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function name"}, {"label": "Input example", "value": "sum"}], "related": [{"url": "/docs/catalog/pg_proc/?v=12", "label": "pg_proc catalog"}, {"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["function name."]}, "13": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function name"}, {"label": "Input example", "value": "sum"}], "related": [{"url": "/docs/catalog/pg_proc/?v=13", "label": "pg_proc catalog"}, {"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["function name."]}, "14": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function name"}, {"label": "Input example", "value": "sum"}], "related": [{"url": "/docs/catalog/pg_proc/?v=14", "label": "pg_proc catalog"}, {"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/14/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.70"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.70 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function name."]}, "15": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function name"}, {"label": "Input example", "value": "sum"}], "related": [{"url": "/docs/catalog/pg_proc/?v=15", "label": "pg_proc catalog"}, {"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/15/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.71"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.71 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function name."]}, "16": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function name"}, {"label": "Input example", "value": "sum"}], "related": [{"url": "/docs/catalog/pg_proc/?v=16", "label": "pg_proc catalog"}, {"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/16/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.72"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.72 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function name."]}, "17": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function name"}, {"label": "Input example", "value": "sum"}], "related": [{"url": "/docs/catalog/pg_proc/?v=17", "label": "pg_proc catalog"}, {"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/17/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.74"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.74 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function name."]}, "18": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function name"}, {"label": "Input example", "value": "sum"}], "related": [{"url": "/docs/catalog/pg_proc/?v=18", "label": "pg_proc catalog"}, {"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/18/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.76"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.76 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function name."]}, "19": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function name"}, {"label": "Input example", "value": "sum"}], "related": [{"url": "/docs/catalog/pg_proc/?v=19", "label": "pg_proc catalog"}, {"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/19/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function name."]}, "20": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function name"}, {"label": "Input example", "value": "sum"}], "related": [{"url": "/docs/catalog/pg_proc/?v=20", "label": "pg_proc catalog"}, {"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL devel online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function name."]}}, "content_hash": "cff57bdce26f27ea8c6854bd8fb5c46e825f72bac6d33b60b19e89d651f9221c", "imported_at": "2026-09-27T09:57:59.108", "url": "/wiki/oid/regproc/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/regproc/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/regproc/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/regproc/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/regproc/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/regproc/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/regproc/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/regproc/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/regproc/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/regproc/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/regproc/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/regproc/?v=20"}], "present": true}, {"slug": "regprocedure", "name": "regprocedure", "name_zh": "regprocedure", "category": "Object name aliases", "summary": "function with argument types.", "aliases": [], "versions": {"10": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function with argument types"}, {"label": "Input example", "value": "sum(int4)"}], "related": [{"url": "/docs/catalog/pg_proc/?v=10", "label": "pg_proc catalog"}, {"url": "/docs/10/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["function with argument types."]}, "11": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function with argument types"}, {"label": "Input example", "value": "sum(int4)"}], "related": [{"url": "/docs/catalog/pg_proc/?v=11", "label": "pg_proc catalog"}, {"url": "/docs/11/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["function with argument types."]}, "12": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function with argument types"}, {"label": "Input example", "value": "sum(int4)"}], "related": [{"url": "/docs/catalog/pg_proc/?v=12", "label": "pg_proc catalog"}, {"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["function with argument types."]}, "13": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function with argument types"}, {"label": "Input example", "value": "sum(int4)"}], "related": [{"url": "/docs/catalog/pg_proc/?v=13", "label": "pg_proc catalog"}, {"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["function with argument types."]}, "14": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function with argument types"}, {"label": "Input example", "value": "sum(int4)"}], "related": [{"url": "/docs/catalog/pg_proc/?v=14", "label": "pg_proc catalog"}, {"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/14/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.70"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.70 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function with argument types."]}, "15": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function with argument types"}, {"label": "Input example", "value": "sum(int4)"}], "related": [{"url": "/docs/catalog/pg_proc/?v=15", "label": "pg_proc catalog"}, {"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/15/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.71"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.71 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function with argument types."]}, "16": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function with argument types"}, {"label": "Input example", "value": "sum(int4)"}], "related": [{"url": "/docs/catalog/pg_proc/?v=16", "label": "pg_proc catalog"}, {"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/16/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.72"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.72 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function with argument types."]}, "17": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function with argument types"}, {"label": "Input example", "value": "sum(int4)"}], "related": [{"url": "/docs/catalog/pg_proc/?v=17", "label": "pg_proc catalog"}, {"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/17/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.74"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.74 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function with argument types."]}, "18": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function with argument types"}, {"label": "Input example", "value": "sum(int4)"}], "related": [{"url": "/docs/catalog/pg_proc/?v=18", "label": "pg_proc catalog"}, {"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/18/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.76"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.76 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function with argument types."]}, "19": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function with argument types"}, {"label": "Input example", "value": "sum(int4)"}], "related": [{"url": "/docs/catalog/pg_proc/?v=19", "label": "pg_proc catalog"}, {"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/19/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function with argument types."]}, "20": {"facts": [{"label": "Referenced catalog", "value": "pg_proc"}, {"label": "Description", "value": "function with argument types"}, {"label": "Input example", "value": "sum(int4)"}], "related": [{"url": "/docs/catalog/pg_proc/?v=20", "label": "pg_proc catalog"}, {"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL devel online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["function with argument types."]}}, "content_hash": "9c572368a27cf5a52aaf3b4e493433fa4d5dac328cc2ca4c70b8330dd8961501", "imported_at": "2026-09-27T09:57:59.112", "url": "/wiki/oid/regprocedure/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/regprocedure/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/regprocedure/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/regprocedure/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/regprocedure/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/regprocedure/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/regprocedure/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/regprocedure/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/regprocedure/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/regprocedure/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/regprocedure/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/regprocedure/?v=20"}], "present": true}, {"slug": "regrole", "name": "regrole", "name_zh": "regrole", "category": "Object name aliases", "summary": "role name.", "aliases": [], "versions": {"10": {"facts": [{"label": "Referenced catalog", "value": "pg_authid"}, {"label": "Description", "value": "role name"}, {"label": "Input example", "value": "smithee"}], "related": [{"url": "/docs/catalog/pg_authid/?v=10", "label": "pg_authid catalog"}, {"url": "/docs/10/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["role name."]}, "11": {"facts": [{"label": "Referenced catalog", "value": "pg_authid"}, {"label": "Description", "value": "role name"}, {"label": "Input example", "value": "smithee"}], "related": [{"url": "/docs/catalog/pg_authid/?v=11", "label": "pg_authid catalog"}, {"url": "/docs/11/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["role name."]}, "12": {"facts": [{"label": "Referenced catalog", "value": "pg_authid"}, {"label": "Description", "value": "role name"}, {"label": "Input example", "value": "smithee"}], "related": [{"url": "/docs/catalog/pg_authid/?v=12", "label": "pg_authid catalog"}, {"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["role name."]}, "13": {"facts": [{"label": "Referenced catalog", "value": "pg_authid"}, {"label": "Description", "value": "role name"}, {"label": "Input example", "value": "smithee"}], "related": [{"url": "/docs/catalog/pg_authid/?v=13", "label": "pg_authid catalog"}, {"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["role name."]}, "14": {"facts": [{"label": "Referenced catalog", "value": "pg_authid"}, {"label": "Description", "value": "role name"}, {"label": "Input example", "value": "smithee"}], "related": [{"url": "/docs/catalog/pg_authid/?v=14", "label": "pg_authid catalog"}, {"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/14/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.70"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.70 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["role name."]}, "15": {"facts": [{"label": "Referenced catalog", "value": "pg_authid"}, {"label": "Description", "value": "role name"}, {"label": "Input example", "value": "smithee"}], "related": [{"url": "/docs/catalog/pg_authid/?v=15", "label": "pg_authid catalog"}, {"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/15/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.71"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.71 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["role name."]}, "16": {"facts": [{"label": "Referenced catalog", "value": "pg_authid"}, {"label": "Description", "value": "role name"}, {"label": "Input example", "value": "smithee"}], "related": [{"url": "/docs/catalog/pg_authid/?v=16", "label": "pg_authid catalog"}, {"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/16/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.72"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.72 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["role name."]}, "17": {"facts": [{"label": "Referenced catalog", "value": "pg_authid"}, {"label": "Description", "value": "role name"}, {"label": "Input example", "value": "smithee"}], "related": [{"url": "/docs/catalog/pg_authid/?v=17", "label": "pg_authid catalog"}, {"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/17/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.74"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.74 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["role name."]}, "18": {"facts": [{"label": "Referenced catalog", "value": "pg_authid"}, {"label": "Description", "value": "role name"}, {"label": "Input example", "value": "smithee"}], "related": [{"url": "/docs/catalog/pg_authid/?v=18", "label": "pg_authid catalog"}, {"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/18/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.76"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.76 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["role name."]}, "19": {"facts": [{"label": "Referenced catalog", "value": "pg_authid"}, {"label": "Description", "value": "role name"}, {"label": "Input example", "value": "smithee"}], "related": [{"url": "/docs/catalog/pg_authid/?v=19", "label": "pg_authid catalog"}, {"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/19/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["role name."]}, "20": {"facts": [{"label": "Referenced catalog", "value": "pg_authid"}, {"label": "Description", "value": "role name"}, {"label": "Input example", "value": "smithee"}], "related": [{"url": "/docs/catalog/pg_authid/?v=20", "label": "pg_authid catalog"}, {"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL devel online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["role name."]}}, "content_hash": "b494970b2c10111a027433a1bc645de0b5bdf2414e1d2cecf096551dda579132", "imported_at": "2026-09-27T09:57:59.116", "url": "/wiki/oid/regrole/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/regrole/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/regrole/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/regrole/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/regrole/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/regrole/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/regrole/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/regrole/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/regrole/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/regrole/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/regrole/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/regrole/?v=20"}], "present": true}, {"slug": "regtype", "name": "regtype", "name_zh": "regtype", "category": "Object name aliases", "summary": "data type name.", "aliases": [], "versions": {"10": {"facts": [{"label": "Referenced catalog", "value": "pg_type"}, {"label": "Description", "value": "data type name"}, {"label": "Input example", "value": "integer"}], "related": [{"url": "/docs/catalog/pg_type/?v=10", "label": "pg_type catalog"}, {"url": "/docs/10/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 10 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["data type name."]}, "11": {"facts": [{"label": "Referenced catalog", "value": "pg_type"}, {"label": "Description", "value": "data type name"}, {"label": "Input example", "value": "integer"}], "related": [{"url": "/docs/catalog/pg_type/?v=11", "label": "pg_type catalog"}, {"url": "/docs/11/runtime-config-compatible.html#GUC-DEFAULT-WITH-OIDS", "label": "default_with_oids"}, {"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.24"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 11 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. OIDs are not added to user-created tables, unless WITH OIDS is specified when the table is created, or the default_with_oids configuration variable is enabled. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.24 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables. So, using a user-created table's OID column as a primary key is discouraged. OIDs are best used only for references to system tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["data type name."]}, "12": {"facts": [{"label": "Referenced catalog", "value": "pg_type"}, {"label": "Description", "value": "data type name"}, {"label": "Input example", "value": "integer"}], "related": [{"url": "/docs/catalog/pg_type/?v=12", "label": "pg_type catalog"}, {"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 12 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid : regproc , regprocedure , regoper , regoperator , regclass , regtype , regrole , regnamespace , regconfig , and regdictionary . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["data type name."]}, "13": {"facts": [{"label": "Referenced catalog", "value": "pg_type"}, {"label": "Description", "value": "data type name"}, {"label": "Input example", "value": "integer"}], "related": [{"url": "/docs/catalog/pg_type/?v=13", "label": "pg_type catalog"}, {"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 13 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq ; the system will not let the sequence be dropped without first removing the default expression. regrole is the only exception for the property. Constants of this type are not allowed in such expressions."]}], "paragraphs": []}, {"title": "Transaction isolation and planning", "blocks": [{"paragraphs": ["The OID alias types do not completely follow transaction isolation rules. The planner also treats them as simple constants, which may result in sub-optimal planning."]}], "paragraphs": []}], "description": ["data type name."]}, "14": {"facts": [{"label": "Referenced catalog", "value": "pg_type"}, {"label": "Description", "value": "data type name"}, {"label": "Input example", "value": "integer"}], "related": [{"url": "/docs/catalog/pg_type/?v=14", "label": "pg_type catalog"}, {"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/14/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.70"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 14 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.70 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["data type name."]}, "15": {"facts": [{"label": "Referenced catalog", "value": "pg_type"}, {"label": "Description", "value": "data type name"}, {"label": "Input example", "value": "integer"}], "related": [{"url": "/docs/catalog/pg_type/?v=15", "label": "pg_type catalog"}, {"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/15/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.71"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 15 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.71 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["data type name."]}, "16": {"facts": [{"label": "Referenced catalog", "value": "pg_type"}, {"label": "Description", "value": "data type name"}, {"label": "Input example", "value": "integer"}], "related": [{"url": "/docs/catalog/pg_type/?v=16", "label": "pg_type catalog"}, {"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/16/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.72"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 16 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.72 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["data type name."]}, "17": {"facts": [{"label": "Referenced catalog", "value": "pg_type"}, {"label": "Description", "value": "data type name"}, {"label": "Input example", "value": "integer"}], "related": [{"url": "/docs/catalog/pg_type/?v=17", "label": "pg_type catalog"}, {"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/17/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.74"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 17 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.74 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["data type name."]}, "18": {"facts": [{"label": "Referenced catalog", "value": "pg_type"}, {"label": "Description", "value": "data type name"}, {"label": "Input example", "value": "integer"}], "related": [{"url": "/docs/catalog/pg_type/?v=18", "label": "pg_type catalog"}, {"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/18/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.76"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 18 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "The oid type itself has few operations beyond comparison. It can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.76 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regrole is an exception to this property. Constants of this type are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["data type name."]}, "19": {"facts": [{"label": "Referenced catalog", "value": "pg_type"}, {"label": "Description", "value": "data type name"}, {"label": "Input example", "value": "integer"}], "related": [{"url": "/docs/catalog/pg_type/?v=19", "label": "pg_type catalog"}, {"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/19/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 19 online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["data type name."]}, "20": {"facts": [{"label": "Referenced catalog", "value": "pg_type"}, {"label": "Description", "value": "data type name"}, {"label": "Input example", "value": "integer"}], "related": [{"url": "/docs/catalog/pg_type/?v=20", "label": "pg_type catalog"}, {"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "Table 8.26"}, {"url": "/docs/devel/functions-info.html#FUNCTIONS-INFO-CATALOG-TABLE", "label": "Table 9.77"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID-TABLE", "label": "PostgreSQL devel online manual"}], "sections": [{"title": "Storage and range", "blocks": [{"paragraphs": ["Object identifiers (OIDs) are used internally by PostgreSQL as primary keys for various system tables. Type oid represents an object identifier. There are also several alias types for oid , each named reg something . Table 8.26 shows an overview.", "The oid type is currently implemented as an unsigned four-byte integer. Therefore, it is not large enough to provide database-wide uniqueness in large databases, or even in large individual tables.", "In some contexts, a 64-bit variant oid8 can be used. It is implemented as an unsigned eight-byte integer. Unlike its oid counterpart, it can ensure uniqueness in large individual tables.", "The oid and oid8 types themselves have few operations beyond comparison. They can be cast to integer, however, and then manipulated using the standard integer operators. (Beware of possible signed-versus-unsigned confusion if you do this.)"]}], "paragraphs": []}, {"title": "Name resolution and search path", "blocks": [{"code": "SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;", "paragraphs": ["The OID alias types have no operations of their own except for specialized input and output routines. These routines are able to accept and display symbolic names for system objects, rather than the raw numeric value that type oid would use. The alias types allow simplified lookup of OID values for objects. For example, to examine the pg_attribute rows related to a table mytable , one could write:"]}, {"code": "SELECT * FROM pg_attribute\n  WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');", "paragraphs": ["rather than:"]}, {"code": "nextval('foo')              operates on sequence foo\nnextval('FOO')              same as above\nnextval('\"Foo\"')            operates on sequence Foo\nnextval('myschema.foo')     operates on myschema.foo\nnextval('\"myschema\".foo')   same as above\nnextval('foo')              searches search path for foo", "paragraphs": ["While that doesn't look all that bad by itself, it's still oversimplified. A far more complicated sub-select would be needed to select the right OID if there are multiple tables named mytable in different schemas. The regclass input converter handles the table lookup according to the schema path setting, and so it does the \u201cright thing\u201d automatically. Similarly, casting a table's OID to regclass is handy for symbolic display of a numeric OID.", "All of the OID alias types for objects that are grouped by namespace accept schema-qualified names, and will display schema-qualified names on output if the object would not be found in the current search path without being qualified. For example, myschema.mytable is acceptable input for regclass (if there is such a table). That value might be output as myschema.mytable , or just mytable , depending on the current search path. The regproc and regoper alias types will only accept input names that are unique (not overloaded), so they are of limited use; for most uses regprocedure or regoperator are more appropriate. For regoperator , unary operators are identified by writing NONE for the unused operand.", "The input functions for these types allow whitespace between tokens, and will fold upper-case letters to lower case, except within double quotes; this is done to make the syntax rules similar to the way object names are written in SQL. Conversely, the output functions will use double quotes if needed to make the output be a valid SQL identifier. For example, the OID of a function named Foo (with upper case F ) taking two integer arguments could be entered as ' \"Foo\" ( int, integer ) '::regprocedure . The output would look like \"Foo\"(integer,integer) . Both the function name and the argument type names could be schema-qualified, too.", "Many built-in PostgreSQL functions accept the OID of a table, or another kind of database object, and for convenience are declared as taking regclass (or the appropriate OID alias type). This means you do not have to look up the object's OID by hand, but can just enter its name as a string literal. For example, the nextval(regclass) function takes a sequence relation's OID, so you could call it like this:"]}], "paragraphs": []}, {"title": "Early and late binding", "blocks": [{"code": "nextval('foo'::text)      foo is looked up at runtime", "paragraphs": ["When you write the argument of such a function as an unadorned literal string, it becomes a constant of type regclass (or the appropriate type). Since this is really just an OID, it will track the originally identified object despite later renaming, schema reassignment, etc. This \u201cearly binding\u201d behavior is usually desirable for object references in column defaults and views. But sometimes you might want \u201clate binding\u201d where the object reference is resolved at run time. To get late-binding behavior, force the constant to be stored as a text constant instead of regclass :"]}, {"paragraphs": ["The to_regclass() function and its siblings can also be used to perform run-time lookups. See Table 9.77 ."]}], "paragraphs": []}, {"title": "Looking up OIDs through the information schema", "blocks": [{"code": "SELECT table_schema, table_name,\n       pg_relation_size((quote_ident(table_schema) || '.' ||\n                         quote_ident(table_name))::regclass)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["Another practical example of use of regclass is to look up the OID of a table listed in the information_schema views, which don't supply such OIDs directly. One might for example wish to call the pg_relation_size() function, which requires the table OID. Taking the above rules into account, the correct way to do that is"]}, {"code": "SELECT pg_relation_size(table_name)\nFROM information_schema.tables\nWHERE ...", "paragraphs": ["The quote_ident() function will take care of double-quoting the identifiers where needed. The seemingly easier"]}, {"paragraphs": ["is not recommended , because it will fail for tables that are outside your search path or have names that require quoting."]}], "paragraphs": []}, {"title": "dependencies", "blocks": [{"paragraphs": ["An additional property of most of the OID alias types is the creation of dependencies. If a constant of one of these types appears in a stored expression (such as a column default expression or view), it creates a dependency on the referenced object. For example, if a column has a default expression nextval('my_seq'::regclass) , PostgreSQL understands that the default expression depends on the sequence my_seq , so the system will not let the sequence be dropped without first removing the default expression. The alternative of nextval('my_seq'::text) does not create a dependency. ( regdatabase and regrole are exceptions to this property. Constants of these types are not allowed in stored expressions.)"]}], "paragraphs": []}], "description": ["data type name."]}}, "content_hash": "b1180e52999fb221c19ab12fd7d25e02df379b1458c13bbeac2187182c424e4c", "imported_at": "2026-09-27T09:57:59.120", "url": "/wiki/oid/regtype/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/regtype/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/regtype/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/regtype/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/regtype/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/regtype/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/regtype/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/regtype/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/regtype/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/regtype/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/regtype/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/regtype/?v=20"}], "present": true}, {"slug": "cid", "name": "cid", "name_zh": "cid", "category": "Transaction and row identifiers", "summary": "A third identifier type used by the system is cid , or command identifier. This is the data type of the system columns cmin and cmax . Command identifiers are also 32-bit quantities.", "aliases": [], "versions": {"10": {"facts": [{"label": "System columns", "value": "cmin, cmax"}], "related": [{"url": "/docs/10/ddl-system-columns.html", "label": "Section 5.4"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 10 online manual"}], "sections": [], "description": ["A third identifier type used by the system is cid , or command identifier. This is the data type of the system columns cmin and cmax . Command identifiers are also 32-bit quantities."]}, "11": {"facts": [{"label": "System columns", "value": "cmin, cmax"}], "related": [{"url": "/docs/11/ddl-system-columns.html", "label": "Section 5.4"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 11 online manual"}], "sections": [], "description": ["A third identifier type used by the system is cid , or command identifier. This is the data type of the system columns cmin and cmax . Command identifiers are also 32-bit quantities."]}, "12": {"facts": [{"label": "System columns", "value": "cmin, cmax"}], "related": [{"url": "/docs/12/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 12 online manual"}], "sections": [], "description": ["A third identifier type used by the system is cid , or command identifier. This is the data type of the system columns cmin and cmax . Command identifiers are also 32-bit quantities."]}, "13": {"facts": [{"label": "System columns", "value": "cmin, cmax"}], "related": [{"url": "/docs/13/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 13 online manual"}], "sections": [], "description": ["A third identifier type used by the system is cid , or command identifier. This is the data type of the system columns cmin and cmax . Command identifiers are also 32-bit quantities."]}, "14": {"facts": [{"label": "System columns", "value": "cmin, cmax"}], "related": [{"url": "/docs/14/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 14 online manual"}], "sections": [], "description": ["A third identifier type used by the system is cid , or command identifier. This is the data type of the system columns cmin and cmax . Command identifiers are also 32-bit quantities."]}, "15": {"facts": [{"label": "System columns", "value": "cmin, cmax"}], "related": [{"url": "/docs/15/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 15 online manual"}], "sections": [], "description": ["A third identifier type used by the system is cid , or command identifier. This is the data type of the system columns cmin and cmax . Command identifiers are also 32-bit quantities."]}, "16": {"facts": [{"label": "System columns", "value": "cmin, cmax"}], "related": [{"url": "/docs/16/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 16 online manual"}], "sections": [], "description": ["A third identifier type used by the system is cid , or command identifier. This is the data type of the system columns cmin and cmax . Command identifiers are also 32-bit quantities."]}, "17": {"facts": [{"label": "System columns", "value": "cmin, cmax"}], "related": [{"url": "/docs/17/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 17 online manual"}], "sections": [], "description": ["A third identifier type used by the system is cid , or command identifier. This is the data type of the system columns cmin and cmax . Command identifiers are also 32-bit quantities."]}, "18": {"facts": [{"label": "System columns", "value": "cmin, cmax"}], "related": [{"url": "/docs/18/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 18 online manual"}], "sections": [], "description": ["A third identifier type used by the system is cid , or command identifier. This is the data type of the system columns cmin and cmax . Command identifiers are also 32-bit quantities."]}, "19": {"facts": [{"label": "System columns", "value": "cmin, cmax"}], "related": [{"url": "/docs/19/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 19 online manual"}], "sections": [], "description": ["A third identifier type used by the system is cid , or command identifier. This is the data type of the system columns cmin and cmax . Command identifiers are also 32-bit quantities."]}, "20": {"facts": [{"label": "System columns", "value": "cmin, cmax"}], "related": [{"url": "/docs/devel/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL devel online manual"}], "sections": [], "description": ["A third identifier type used by the system is cid , or command identifier. This is the data type of the system columns cmin and cmax . Command identifiers are also 32-bit quantities."]}}, "content_hash": "55a0ea25e52a7db7ef951bc848afe9b3879553f80815efd3fc4f5e3b023532f7", "imported_at": "2026-09-27T09:57:59.069", "url": "/wiki/oid/cid/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/cid/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/cid/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/cid/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/cid/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/cid/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/cid/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/cid/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/cid/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/cid/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/cid/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/cid/?v=20"}], "present": true}, {"slug": "tid", "name": "tid", "name_zh": "tid", "category": "Transaction and row identifiers", "summary": "A final identifier type used by the system is tid , or tuple identifier (row identifier). This is the data type of the system column ctid . A tuple ID is a pair (block number, tuple index within block) that identifies the physical location of the row within its table.", "aliases": [], "versions": {"10": {"facts": [{"label": "System columns", "value": "ctid"}], "related": [{"url": "/docs/10/ddl-system-columns.html", "label": "Section 5.4"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 10 online manual"}], "sections": [], "description": ["A final identifier type used by the system is tid , or tuple identifier (row identifier). This is the data type of the system column ctid . A tuple ID is a pair (block number, tuple index within block) that identifies the physical location of the row within its table."]}, "11": {"facts": [{"label": "System columns", "value": "ctid"}], "related": [{"url": "/docs/11/ddl-system-columns.html", "label": "Section 5.4"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 11 online manual"}], "sections": [], "description": ["A final identifier type used by the system is tid , or tuple identifier (row identifier). This is the data type of the system column ctid . A tuple ID is a pair (block number, tuple index within block) that identifies the physical location of the row within its table."]}, "12": {"facts": [{"label": "System columns", "value": "ctid"}], "related": [{"url": "/docs/12/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 12 online manual"}], "sections": [], "description": ["A final identifier type used by the system is tid , or tuple identifier (row identifier). This is the data type of the system column ctid . A tuple ID is a pair (block number, tuple index within block) that identifies the physical location of the row within its table."]}, "13": {"facts": [{"label": "System columns", "value": "ctid"}], "related": [{"url": "/docs/13/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 13 online manual"}], "sections": [], "description": ["A final identifier type used by the system is tid , or tuple identifier (row identifier). This is the data type of the system column ctid . A tuple ID is a pair (block number, tuple index within block) that identifies the physical location of the row within its table."]}, "14": {"facts": [{"label": "System columns", "value": "ctid"}], "related": [{"url": "/docs/14/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 14 online manual"}], "sections": [], "description": ["A final identifier type used by the system is tid , or tuple identifier (row identifier). This is the data type of the system column ctid . A tuple ID is a pair (block number, tuple index within block) that identifies the physical location of the row within its table."]}, "15": {"facts": [{"label": "System columns", "value": "ctid"}], "related": [{"url": "/docs/15/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 15 online manual"}], "sections": [], "description": ["A final identifier type used by the system is tid , or tuple identifier (row identifier). This is the data type of the system column ctid . A tuple ID is a pair (block number, tuple index within block) that identifies the physical location of the row within its table."]}, "16": {"facts": [{"label": "System columns", "value": "ctid"}], "related": [{"url": "/docs/16/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 16 online manual"}], "sections": [], "description": ["A final identifier type used by the system is tid , or tuple identifier (row identifier). This is the data type of the system column ctid . A tuple ID is a pair (block number, tuple index within block) that identifies the physical location of the row within its table."]}, "17": {"facts": [{"label": "System columns", "value": "ctid"}], "related": [{"url": "/docs/17/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 17 online manual"}], "sections": [], "description": ["A final identifier type used by the system is tid , or tuple identifier (row identifier). This is the data type of the system column ctid . A tuple ID is a pair (block number, tuple index within block) that identifies the physical location of the row within its table."]}, "18": {"facts": [{"label": "System columns", "value": "ctid"}], "related": [{"url": "/docs/18/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 18 online manual"}], "sections": [], "description": ["A final identifier type used by the system is tid , or tuple identifier (row identifier). This is the data type of the system column ctid . A tuple ID is a pair (block number, tuple index within block) that identifies the physical location of the row within its table."]}, "19": {"facts": [{"label": "System columns", "value": "ctid"}], "related": [{"url": "/docs/19/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 19 online manual"}], "sections": [], "description": ["A final identifier type used by the system is tid , or tuple identifier (row identifier). This is the data type of the system column ctid . A tuple ID is a pair (block number, tuple index within block) that identifies the physical location of the row within its table."]}, "20": {"facts": [{"label": "System columns", "value": "ctid"}], "related": [{"url": "/docs/devel/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL devel online manual"}], "sections": [], "description": ["A final identifier type used by the system is tid , or tuple identifier (row identifier). This is the data type of the system column ctid . A tuple ID is a pair (block number, tuple index within block) that identifies the physical location of the row within its table."]}}, "content_hash": "a9a261dad74c2af850943403404b48ff885eda3167ab7d6e53f753fe5e5dfcb2", "imported_at": "2026-09-27T09:57:59.125", "url": "/wiki/oid/tid/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/tid/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/tid/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/tid/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/tid/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/tid/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/tid/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/tid/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/tid/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/tid/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/tid/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/tid/?v=20"}], "present": true}, {"slug": "xid", "name": "xid", "name_zh": "xid", "category": "Transaction and row identifiers", "summary": "Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster. See Section 67.1 for more details.", "aliases": [], "versions": {"10": {"facts": [{"label": "System columns", "value": "xmin, xmax"}], "related": [{"url": "/docs/10/ddl-system-columns.html", "label": "Section 5.4"}], "release": {"ref": "PostgreSQL 10.23 Documentation", "label": "10.23", "major": "10", "channel": "historical", "revision": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, "sources": [{"url": "/docs/10/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 10.23 Documentation", "sha256": "92d3c4a6201e06b2aea6dabfa4867cf6d1b2f66c2eb53b77ed08646b3068c291"}, {"url": "https://www.postgresql.org/docs/10/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 10 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities."]}, "11": {"facts": [{"label": "System columns", "value": "xmin, xmax"}], "related": [{"url": "/docs/11/ddl-system-columns.html", "label": "Section 5.4"}], "release": {"ref": "PostgreSQL 11.22 Documentation", "label": "11.22", "major": "11", "channel": "historical", "revision": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, "sources": [{"url": "/docs/11/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 11.22 Documentation", "sha256": "a1cc37e5ce5c2d09ce06539704c618a2d418f54eaaa35365e8c547d2aaa06311"}, {"url": "https://www.postgresql.org/docs/11/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 11 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities."]}, "12": {"facts": [{"label": "System columns", "value": "xmin, xmax"}], "related": [{"url": "/docs/12/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 12.22 Documentation", "label": "12.22", "major": "12", "channel": "historical", "revision": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, "sources": [{"url": "/docs/12/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 12.22 Documentation", "sha256": "5675d9e3b694f46538248a1a9f533609078817a7b6d469c53533973cbfaecc8c"}, {"url": "https://www.postgresql.org/docs/12/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 12 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities."]}, "13": {"facts": [{"label": "System columns", "value": "xmin, xmax"}], "related": [{"url": "/docs/13/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 13 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster."]}, "14": {"facts": [{"label": "System columns", "value": "xmin, xmax"}], "related": [{"url": "/docs/14/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 14 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster."]}, "15": {"facts": [{"label": "System columns", "value": "xmin, xmax"}], "related": [{"url": "/docs/15/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 15 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster."]}, "16": {"facts": [{"label": "System columns", "value": "xmin, xmax"}], "related": [{"url": "/docs/16/transaction-id.html", "label": "Section 74.1"}, {"url": "/docs/16/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 16 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster. See Section 74.1 for more details."]}, "17": {"facts": [{"label": "System columns", "value": "xmin, xmax"}], "related": [{"url": "/docs/17/transaction-id.html", "label": "Section 66.1"}, {"url": "/docs/17/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 17 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster. See Section 66.1 for more details."]}, "18": {"facts": [{"label": "System columns", "value": "xmin, xmax"}], "related": [{"url": "/docs/18/transaction-id.html", "label": "Section 67.1"}, {"url": "/docs/18/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 18 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster. See Section 67.1 for more details."]}, "19": {"facts": [{"label": "System columns", "value": "xmin, xmax"}], "related": [{"url": "/docs/19/transaction-id.html", "label": "Section 67.1"}, {"url": "/docs/19/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 19 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster. See Section 67.1 for more details."]}, "20": {"facts": [{"label": "System columns", "value": "xmin, xmax"}], "related": [{"url": "/docs/devel/transaction-id.html", "label": "Section 67.1"}, {"url": "/docs/devel/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL devel online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster. See Section 67.1 for more details."]}}, "content_hash": "a843fead858d38f2a180bd49d568f12c72609c779047fdacefbbc53dd8c6dd2f", "imported_at": "2026-09-27T09:57:59.126", "url": "/wiki/oid/xid/?v=18", "cells": [{"major": "10", "state": "present", "label": "Recorded", "title": "PostgreSQL 10.23 \u00b7 Recorded", "url": "/wiki/oid/xid/?v=10"}, {"major": "11", "state": "present", "label": "Recorded", "title": "PostgreSQL 11.22 \u00b7 Recorded", "url": "/wiki/oid/xid/?v=11"}, {"major": "12", "state": "present", "label": "Recorded", "title": "PostgreSQL 12.22 \u00b7 Recorded", "url": "/wiki/oid/xid/?v=12"}, {"major": "13", "state": "present", "label": "Recorded", "title": "PostgreSQL 13.23 \u00b7 Recorded", "url": "/wiki/oid/xid/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/xid/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/xid/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/xid/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/xid/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/xid/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/xid/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/xid/?v=20"}], "present": true}, {"slug": "xid8", "name": "xid8", "name_zh": "xid8", "category": "Transaction and row identifiers", "summary": "Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster. See Section 67.1 for more details.", "aliases": [], "versions": {"13": {"facts": [], "related": [{"url": "/docs/13/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 13.23 Documentation", "label": "13.23", "major": "13", "channel": "historical", "revision": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, "sources": [{"url": "/docs/13/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 13.23 Documentation", "sha256": "e8d8a34f63902cffef02459d02c2eefdf066463f9cb979c0b0b70f6659ff2bf0"}, {"url": "https://www.postgresql.org/docs/13/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 13 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster."]}, "14": {"facts": [], "related": [{"url": "/docs/14/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 14.24 Documentation", "label": "14.24", "major": "14", "channel": "stable", "revision": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, "sources": [{"url": "/docs/14/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 14.24 Documentation", "sha256": "b689bc079f1ebb4b03dd138db6e1bef615d018d2cfa6f7108fab7dbdda3282bd"}, {"url": "https://www.postgresql.org/docs/14/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 14 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster."]}, "15": {"facts": [], "related": [{"url": "/docs/15/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 15.19 Documentation", "label": "15.19", "major": "15", "channel": "stable", "revision": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, "sources": [{"url": "/docs/15/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 15.19 Documentation", "sha256": "f10a38f34aecafe53113185b7e56d667b2d7d33905acde2aeef4a6fec76ff9d6"}, {"url": "https://www.postgresql.org/docs/15/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 15 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster."]}, "16": {"facts": [], "related": [{"url": "/docs/16/transaction-id.html", "label": "Section 74.1"}, {"url": "/docs/16/ddl-system-columns.html", "label": "Section 5.5"}], "release": {"ref": "PostgreSQL 16.15 Documentation", "label": "16.15", "major": "16", "channel": "stable", "revision": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, "sources": [{"url": "/docs/16/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 16.15 Documentation", "sha256": "24d2f393c5bcc7ff47d33e9a61479d00dcc99825ae296491771e340391f24384"}, {"url": "https://www.postgresql.org/docs/16/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 16 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster. See Section 74.1 for more details."]}, "17": {"facts": [], "related": [{"url": "/docs/17/transaction-id.html", "label": "Section 66.1"}, {"url": "/docs/17/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 17.11 Documentation", "label": "17.11", "major": "17", "channel": "stable", "revision": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, "sources": [{"url": "/docs/17/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 17.11 Documentation", "sha256": "f58cc823839afa25edb5df244b0a27ad24aa1d62d2d14870e9117eda6f619a74"}, {"url": "https://www.postgresql.org/docs/17/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 17 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster. See Section 66.1 for more details."]}, "18": {"facts": [], "related": [{"url": "/docs/18/transaction-id.html", "label": "Section 67.1"}, {"url": "/docs/18/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 18.6 Documentation", "label": "18.6", "major": "18", "channel": "stable", "revision": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, "sources": [{"url": "/docs/18/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 18.6 Documentation", "sha256": "8b3360302225f08ae72716ce1804596de95b568e5d31f788cb4597427b28cc38"}, {"url": "https://www.postgresql.org/docs/18/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 18 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster. See Section 67.1 for more details."]}, "19": {"facts": [], "related": [{"url": "/docs/19/transaction-id.html", "label": "Section 67.1"}, {"url": "/docs/19/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 19beta4 Documentation", "label": "19beta4", "major": "19", "channel": "preview", "revision": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, "sources": [{"url": "/docs/19/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 19beta4 Documentation", "sha256": "1985075ff3a6bdd8f41bf558847d8707b87c3103aff3c86ad4b627ac7f2d3756"}, {"url": "https://www.postgresql.org/docs/19/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 19 online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster. See Section 67.1 for more details."]}, "20": {"facts": [], "related": [{"url": "/docs/devel/transaction-id.html", "label": "Section 67.1"}, {"url": "/docs/devel/ddl-system-columns.html", "label": "Section 5.6"}], "release": {"ref": "PostgreSQL 20devel Documentation", "label": "20devel", "major": "20", "channel": "devel", "revision": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, "sources": [{"url": "/docs/devel/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL 20devel Documentation", "sha256": "dc75e7ebcf3d74dccbbc22ff10acdddc868b64becff49460d7f6ae89659f8be4"}, {"url": "https://www.postgresql.org/docs/devel/datatype-oid.html#DATATYPE-OID", "label": "PostgreSQL devel online manual"}], "sections": [], "description": ["Another identifier type used by the system is xid , or transaction (abbreviated xact ) identifier. This is the data type of the system columns xmin and xmax . Transaction identifiers are 32-bit quantities. In some contexts, a 64-bit variant xid8 is used. Unlike xid values, xid8 values increase strictly monotonically and cannot be reused in the lifetime of a database cluster. See Section 67.1 for more details."]}}, "content_hash": "0f1b788cd324f2406f1c461f19c76f0ce72fee217e8e373e2e7e4f89721144cb", "imported_at": "2026-09-27T09:57:59.128", "url": "/wiki/oid/xid8/?v=18", "cells": [{"major": "10", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 10.23 \u00b7 Not recorded in this version", "url": "/wiki/oid/xid8/?v=10"}, {"major": "11", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 11.22 \u00b7 Not recorded in this version", "url": "/wiki/oid/xid8/?v=11"}, {"major": "12", "state": "absent", "label": "Not recorded in this version", "title": "PostgreSQL 12.22 \u00b7 Not recorded in this version", "url": "/wiki/oid/xid8/?v=12"}, {"major": "13", "state": "added", "label": "First recorded in this sample", "title": "PostgreSQL 13.23 \u00b7 First recorded in this sample", "url": "/wiki/oid/xid8/?v=13"}, {"major": "14", "state": "present", "label": "Recorded", "title": "PostgreSQL 14.24 \u00b7 Recorded", "url": "/wiki/oid/xid8/?v=14"}, {"major": "15", "state": "present", "label": "Recorded", "title": "PostgreSQL 15.19 \u00b7 Recorded", "url": "/wiki/oid/xid8/?v=15"}, {"major": "16", "state": "present", "label": "Recorded", "title": "PostgreSQL 16.15 \u00b7 Recorded", "url": "/wiki/oid/xid8/?v=16"}, {"major": "17", "state": "present", "label": "Recorded", "title": "PostgreSQL 17.11 \u00b7 Recorded", "url": "/wiki/oid/xid8/?v=17"}, {"major": "18", "state": "present", "label": "Recorded", "title": "PostgreSQL 18.6 \u00b7 Recorded", "url": "/wiki/oid/xid8/?v=18"}, {"major": "19", "state": "present", "label": "Recorded", "title": "PostgreSQL 19beta4 \u00b7 Recorded", "url": "/wiki/oid/xid8/?v=19"}, {"major": "20", "state": "present", "label": "Recorded", "title": "PostgreSQL 20devel \u00b7 Recorded", "url": "/wiki/oid/xid8/?v=20"}], "present": true}], "total": 18, "present": 16, "collection_tables": []}