{"kind": "oid", "major": "18", "item": {"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"}, "snapshot": {"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."]}, "comparison": {"left": "17", "right": "18", "status": "unchanged", "diff": ""}}