DBLINK(3)

💅 DBLINK(3) — the dblink page, bestie edition ✨

okay so this is the PostgreSQL dblink manual page (we're on PostgreSQL 15.19, keep that in your notes 📝) and honestly? it's gonna change your whole remote-query situation. stay with me 🫶

---

✨ NAME ✨

dblink — literally executes a query in a remote database. that's the whole vibe. 💫

---

🌸 SYNOPSIS 🌸

dblink(text connname, text sql [, bool fail_on_error]) returns setof record
dblink(text connstr, text sql [, bool fail_on_error]) returns setof record
dblink(text sql [, bool fail_on_error]) returns setof record

three flavors, pick your fighter 👑 the square brackets mean that last argument is optional, iykyk.

---

🦋 DESCRIPTION 🦋

so dblink executes a query in a remote database. usually that's a SELECT, but fr fr it can be any SQL statement that returns rows — no gatekeeping here 💅

now here's the cute part: when you hand it two text arguments, the first one gets looked up first as a persistent connection's name. if it's found, the command runs on that connection, easy. if it's not found, that first argument gets treated as a connection info string just like the one for dblink_connect, and the indicated connection gets made just for the duration of this command. one-night-stand connection, we love to see it 💀

---

🎀 ARGUMENTS 🎀

• connname — the name of the connection to use. omit this parameter and you'll be using the unnamed connection instead. main character energy, no name needed ✨
• connstr — a connection info string, as previously described for dblink_connect. it's giving "go read that page too" but respectfully 🫶
• sql — the SQL query you wish to execute in the remote database, for example select * from foo. go off, queen 🔥
• fail_on_error — if true (which is the default when you omit it), then an error thrown on the remote side of the connection causes an error to also be thrown locally. loud and proud. if false, the remote error gets locally reported as a NOTICE, and the function returns no rows. so like, the drama gets downgraded to a whisper 🙈

---

⭐ RETURN VALUE ⭐

the function returns the row(s) produced by the query. and because dblink can be used with any query, it's declared to return record rather than committing to any particular set of columns. commitment issues, honestly 💀

which means: you must specify the expected set of columns in the calling query — otherwise PostgreSQL would not know what to expect. no cap, it just wouldn't. here's an example:

SELECT *
    FROM dblink('dbname=mydb options=-csearch_path=',
                'select proname, prosrc from pg_proc')
      AS t1(proname name, prosrc text)
    WHERE proname LIKE 'bytea%';

the "alias" part of the FROM clause must specify the column names and types that the function will return. (fun fact: specifying column names in an alias is actually standard SQL syntax, but specifying column types is a PostgreSQL extension — we're built different 💅) this lets the system understand what * should expand to, and what proname in the WHERE clause refers to, before it even tries to execute the function. foresight, iconic.

at run time, an error will be thrown if the actual query result from the remote database doesn't have the same number of columns shown in the FROM clause. the column names need not match, though, and dblink doesn't insist on exact type matches either. it will succeed so long as the returned data strings are valid input for the column type declared in the FROM clause. flexible but with boundaries, we stan 🌈

---

💖 NOTES 💖

a convenient way to use dblink with predetermined queries is to create a view. this lets the column type information be buried in the view instead of having to spell it out in every single query. lazy girlie hack, but make it architecture ✨ for example:

CREATE VIEW myremote_pg_proc AS
  SELECT *
    FROM dblink('dbname=postgres options=-csearch_path=',
                'select proname, prosrc from pg_proc')
    AS t1(proname name, prosrc text);

SELECT * FROM myremote_pg_proc WHERE proname LIKE 'bytea%';

---

🔥 EXAMPLES 🔥

okay bestie, buckle up, we got four of them 🎢

one — inline connection string, no named connection:

SELECT * FROM dblink('dbname=postgres options=-csearch_path=',
                     'select proname, prosrc from pg_proc')
  AS t1(proname name, prosrc text) WHERE proname LIKE 'bytea%';
  proname   |   prosrc
------------+------------
 byteacat   | byteacat
 byteaeq    | byteaeq
 bytealt    | bytealt
 byteale    | byteale
 byteagt    | byteagt
 byteage    | byteage
 byteane    | byteane
 byteacmp   | byteacmp
 bytealike  | bytealike
 byteanlike | byteanlike
 byteain    | byteain
 byteaout   | byteaout
(12 rows)

two — connect to the unnamed connection first:

SELECT dblink_connect('dbname=postgres options=-csearch_path=');
 dblink_connect
----------------
 OK
(1 row)

three — now query through that unnamed connection:

SELECT * FROM dblink('select proname, prosrc from pg_proc')
  AS t1(proname name, prosrc text) WHERE proname LIKE 'bytea%';
  proname   |   prosrc
------------+------------
 byteacat   | byteacat
 byteaeq    | byteaeq
 bytealt    | bytealt
 byteale    | byteale
 byteagt    | byteagt
 byteage    | byteage
 byteane    | byteane
 byteacmp   | byteacmp
 bytealike  | bytealike
 byteanlike | byteanlike
 byteain    | byteain
 byteaout   | byteaout
(12 rows)

four — now with a named connection called myconn:

SELECT dblink_connect('myconn', 'dbname=regression options=-csearch_path=');
 dblink_connect
----------------
 OK
(1 row)

and then query it by name 👇

SELECT * FROM dblink('myconn', 'select proname, prosrc from pg_proc')
  AS t1(proname name, prosrc text) WHERE proname LIKE 'bytea%';
  proname   |   prosrc
------------+------------
 bytearecv  | bytearecv
 byteasend  | byteasend
 byteale    | byteale
 byteagt    | byteagt
 byteage    | byteage
 byteane    | byteane
 byteacmp   | byteacmp
 bytealike  | bytealike
 byteanlike | byteanlike
 byteacat   | byteacat
 byteaeq    | byteaeq
 bytealt    | bytealt
 byteain    | byteain
 byteaout   | byteaout
(14 rows)

note that last one gave you 14 rows, not 12 — the connection points at regression this time, so the results are different. the way the row counts change based on which database you're hitting... obsessed 😭✨

---

anyway that's the whole page, you're welcome, go execute some remote queries responsibly 🧚💜

source + version + date, for the record: PostgreSQL 15.19, dated 2026. mwah, bye bestie 🎀💋