Chapter 35. The Information Schema

Table of Contents

35.1. The Schema
35.2. Data Types
35.3. information_schema_catalog_name
35.4. administrable_role_​authorizations
35.5. applicable_roles
35.6. attributes
35.7. character_sets
35.8. check_constraint_routine_usage
35.9. check_constraints
35.10. collations
35.11. collation_character_set_​applicability
35.12. column_column_usage
35.13. column_domain_usage
35.14. column_options
35.15. column_privileges
35.16. column_udt_usage
35.17. columns
35.18. constraint_column_usage
35.19. constraint_table_usage
35.20. data_type_privileges
35.21. domain_constraints
35.22. domain_udt_usage
35.23. domains
35.24. element_types
35.25. enabled_roles
35.26. foreign_data_wrapper_options
35.27. foreign_data_wrappers
35.28. foreign_server_options
35.29. foreign_servers
35.30. foreign_table_options
35.31. foreign_tables
35.32. key_column_usage
35.33. parameters
35.34. referential_constraints
35.35. role_column_grants
35.36. role_routine_grants
35.37. role_table_grants
35.38. role_udt_grants
35.39. role_usage_grants
35.40. routine_privileges
35.41. routines
35.42. schemata
35.43. sequences
35.44. sql_features
35.45. sql_implementation_info
35.46. sql_parts
35.47. sql_sizing
35.48. table_constraints
35.49. table_privileges
35.50. tables
35.51. triggered_update_columns
35.52. triggers
35.53. udt_privileges
35.54. usage_privileges
35.55. user_defined_types
35.56. user_mapping_options
35.57. user_mappings
35.58. view_column_usage
35.59. view_routine_usage
35.60. view_table_usage
35.61. views

The information schema consists of a set of views that contain information about the objects defined in the current database. The information schema is defined in the SQL standard and can therefore be expected to be portable and remain stable — unlike the system catalogs, which are specific to LightDB and are modeled after implementation concerns. The information schema views do not, however, contain information about LightDB-specific features; to inquire about those you need to query the system catalogs or other LightDB-specific views.

Note

When querying the database for constraint information, it is possible for a standard-compliant query that expects to return one row to return several. This is because the SQL standard requires constraint names to be unique within a schema, but LightDB does not enforce this restriction. LightDB automatically-generated constraint names avoid duplicates in the same schema, but users can specify such duplicate names.

This problem can appear when querying information schema views such as check_constraint_routine_usage, check_constraints, domain_constraints, and referential_constraints. Some other views have similar issues but contain the table name to help distinguish duplicate rows, e.g., constraint_column_usage, constraint_table_usage, table_constraints.