CREATE_FOREIGN_DATA_WRAPPER(7pg15)

πŸ“¦ version 15.19, in opensuse-leap 16.0

🌸 NAME 🌸

CREATE_FOREIGN_DATA_WRAPPER β€” define a new foreign-data wrapper. Okay bestie, this is the PostgreSQL 15.19 Documentation page for CREATE FOREIGN DATA WRAPPER (7), and we are absolutely about to make a brand-new foreign-data wrapper together πŸ’…βœ¨

✨ SYNOPSIS ✨

CREATE FOREIGN DATA WRAPPER name
    [ HANDLER handler_function | NO HANDLER ]
    [ VALIDATOR validator_function | NO VALIDATOR ]
    [ OPTIONS ( option 'value' [, ... ] ) ]

πŸ’– DESCRIPTION πŸ’–

CREATE FOREIGN DATA WRAPPER creates a new foreign-data wrapper. Whoever defines the foreign-data wrapper becomes its owner β€” main character energy πŸ‘‘.

The foreign-data wrapper name must be unique within the database, no duplicates allowed, periodt.

Only superusers can create foreign-data wrappers β€” that's the vibe check πŸ”₯.

πŸŽ€ PARAMETERS πŸŽ€

  • name β€” the name of the foreign-data wrapper to be created. Cute and simple πŸ’–
  • HANDLER handler_function β€” handler_function is the name of a previously registered function that will be called to retrieve the execution functions for foreign tables. The handler function must take no arguments, and its return type must be fdw_handler. It is possible to create a foreign-data wrapper with no handler function, but foreign tables using such a wrapper can only be declared, not accessed. So like, they can exist but not be accessed β€” noted 🫢
  • VALIDATOR validator_function β€” validator_function is the name of a previously registered function that will be called to check the generic options given to the foreign-data wrapper, as well as options for foreign servers, user mappings and foreign tables using the foreign-data wrapper. If no validator function or NO VALIDATOR is specified, then options will not be checked at creation time. (Foreign-data wrappers will possibly ignore or reject invalid option specifications at run time, depending on the implementation.) The validator function must take two arguments: one of type text[], which will contain the array of options as stored in the system catalogs, and one of type oid, which will be the OID of the system catalog containing the options. The return type is ignored; the function should report invalid options using the ereport(ERROR) function.
  • OPTIONS ( option 'value' [, ... ] ) β€” this clause specifies options for the new foreign-data wrapper. The allowed option names and values are specific to each foreign data wrapper and are validated using the foreign-data wrapper's validator function. Option names must be unique. No sharing names, bestie 🚫

🌈 NOTES 🌈

PostgreSQL's foreign-data functionality is still under active development β€” yes, it's giving work in progress 🚧. Optimization of queries is primitive (and mostly left to the wrapper, too). Thus, there is considerable room for future performance improvements. So like, future you might eat, but present you is chilling with the current vibe ✨

πŸ¦‹ EXAMPLES πŸ¦‹

Create a useless foreign-data wrapper dummy:

CREATE FOREIGN DATA WRAPPER dummy;

Create a foreign-data wrapper file with handler function file_fdw_handler:

CREATE FOREIGN DATA WRAPPER file HANDLER file_fdw_handler;

Create a foreign-data wrapper mywrapper with some options:

CREATE FOREIGN DATA WRAPPER mywrapper
    OPTIONS (debug 'true');

πŸ’œ COMPATIBILITY πŸ’œ

CREATE FOREIGN DATA WRAPPER conforms to ISO/IEC 9075-9 (SQL/MED), with the exception that the HANDLER and VALIDATOR clauses are extensions and the standard clauses LIBRARY and LANGUAGE are not implemented in PostgreSQL.

Note, however, that the SQL/MED functionality as a whole is not yet conforming. That's the compatibility tea, no cap β˜•

πŸ‘‘ SEE ALSO πŸ‘‘


PostgreSQL 15.19 Β· 2026 β€” that's the source/version and date from the footer, bestie. Now go make a wrapper and slay πŸ’–βœ¨πŸ«Ά

πŸ“¦ where this page comes from