57.1. Функции обёрток сторонних данных
Автор FDW (Foreign Data Wrapper, Обёртки сторонних данных) должен реализовать функцию-обработчик и может дополнительно добавить функцию проверки. Обе функции должны быть написаны на компилируемом языке, таком как C, и использовать интерфейс версии 1. Подробнее соглашение о вызовах и динамическая загрузка кода на C описывается в Разделе 40.10.
Функция-обработчик просто возвращает структуру с указателями на реализующие подпрограммы, которые будут вызываться планировщиком, исполнителем и различными служебными командами. Основная часть разработки FDW заключается в написании этих реализующих подпрограмм. Функция-обработчик должна быть зарегистрирована в Postgres Pro как функция без аргументов, возвращающая специальный псевдотип fdw_handler. Реализующие подпрограммы представляют собой обычные функции на C, которые не видны и не могут вызываться на уровне SQL. Они описаны в Разделе 57.2.
Функция проверки отвечает за проверку параметров, передаваемых с командами CREATE и ALTER для этой обёртки сторонних данных, а также параметров сторонних серверов, сопоставлений пользователей и сторонних таблиц, доступных через эту обёртку. Эта функция должна быть зарегистрирована как принимающая два аргумента: текстовый массив, содержащий параметры для проверки, и OID, представляющий тип объекта, с которым связаны эти параметры. Второй аргумент соответствует OID системного каталога, в котором будет сохраняться объект:
AttributeRelationIdForeignDataWrapperRelationIdForeignServerRelationIdForeignTableRelationIdUserMappingRelationId
. Если функция проверки отсутствует, параметры не проверяются ни при создании, ни при изменении объекта.
Chapter 36. The Information Schema
Table of Contents
- 36.1. The Schema
- 36.2. Data Types
- 36.3.
information_schema_catalog_name - 36.4.
administrable_role_authorizations - 36.5.
applicable_roles - 36.6.
attributes - 36.7.
character_sets - 36.8.
check_constraint_routine_usage - 36.9.
check_constraints - 36.10.
collations - 36.11.
collation_character_set_applicability - 36.12.
column_column_usage - 36.13.
column_domain_usage - 36.14.
column_options - 36.15.
column_privileges - 36.16.
column_udt_usage - 36.17.
columns - 36.18.
constraint_column_usage - 36.19.
constraint_table_usage - 36.20.
data_type_privileges - 36.21.
domain_constraints - 36.22.
domain_udt_usage - 36.23.
domains - 36.24.
element_types - 36.25.
enabled_roles - 36.26.
foreign_data_wrapper_options - 36.27.
foreign_data_wrappers - 36.28.
foreign_server_options - 36.29.
foreign_servers - 36.30.
foreign_table_options - 36.31.
foreign_tables - 36.32.
key_column_usage - 36.33.
parameters - 36.34.
referential_constraints - 36.35.
role_column_grants - 36.36.
role_routine_grants - 36.37.
role_table_grants - 36.38.
role_udt_grants - 36.39.
role_usage_grants - 36.40.
routine_column_usage - 36.41.
routine_privileges - 36.42.
routine_routine_usage - 36.43.
routine_sequence_usage - 36.44.
routine_table_usage - 36.45.
routines - 36.46.
schemata - 36.47.
sequences - 36.48.
sql_features - 36.49.
sql_implementation_info - 36.50.
sql_parts - 36.51.
sql_sizing - 36.52.
table_constraints - 36.53.
table_privileges - 36.54.
tables - 36.55.
transforms - 36.56.
triggered_update_columns - 36.57.
triggers - 36.58.
udt_privileges - 36.59.
usage_privileges - 36.60.
user_defined_types - 36.61.
user_mapping_options - 36.62.
user_mappings - 36.63.
view_column_usage - 36.64.
view_routine_usage - 36.65.
view_table_usage - 36.66.
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 Postgres Pro and are modeled after implementation concerns. The information schema views do not, however, contain information about Postgres Pro-specific features; to inquire about those you need to query the system catalogs or other Postgres Pro-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 Postgres Pro does not enforce this restriction. Postgres Pro 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.