DBLINK(3)

🌸 NAME 🌸

dblink — bestie's little teleporter that runs a query in a remote database ✨

(this is from the PostgreSQL 17.11 docs, and it is so useful, iykyk)

---

🎀 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

---

🦋 DESCRIPTION 🦋

okay so dblink executes a query — usually a SELECT, but honestly it can be any SQL statement that returns rows — in a remote database. main character behavior, truly. 💅

and here's the iconic part: when you hand it two text arguments, it first looks up the first one as a persistent connection's name. if it finds it, the command runs on that connection. if not, the first argument gets treated as a connection info string, exactly like for dblink_connect, and the indicated connection is made just for the duration of this command. no strings attached, no cap. 🫶

---

💖 ARGUMENTS 💖

• connname — the name of the connection you wanna use. omit this parameter and it'll use the unnamed connection instead. (yes, the nameless one. she exists.)
• connstr — a connection info string, as previously described for dblink_connect. that's the whole vibe.
• sql — the actual 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 omitted, fyi) then an error thrown on the remote side of the connection causes an error to also be thrown locally. if false, the remote error is locally reported as a NOTICE instead — and the function returns no rows. 🫠

---

👑 RETURN VALUE 👑

the function returns the row(s) produced by the query. and because dblink can be used with literally any query, it's declared to return record rather than specifying any particular set of columns. which lowkey means you have to specify the expected set of columns in the calling query — otherwise PostgreSQL would not know what to expect. 😭

here's the example, slay:

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

so the “alias” part of the FROM clause must specify the column names and types that the function will return. (specifying column names in an alias is actually standard SQL syntax, but specifying column types is a PostgreSQL extension, just so you know.) this is what lets the system understand what * should expand to, and what proname in the WHERE clause refers to, in advance of trying 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, however, and dblink does not 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 firm. we love a boundary-setting function. 💅

---

🌈 NOTES 🌈

a convenient way to use dblink with predetermined queries is to create a view — that way the column type information gets buried in the view instead of having to spell it out in every single query. efficiency!! 🧚

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 ⭐

starting with the full connection-string situation:

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)

then we set up the unnamed connection and skip the connstr entirely:

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

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)

aaaand now a named connection, because sometimes you want her to have a name:

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

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)

ngl, note that the last one returns 14 rows and not 12 — that's dbname=regression, bestie, a whole different database with a whole different pg_proc. the vibes differ. 🙈

---

and that's the whole page, periodt 💜 — this was PostgreSQL 17.11, dated 2026, filed under DBLINK(3). go forth and link those dbs, you absolute icon 🎀✨