DBLINK(3)

okay so this is DBLINK(3) from the PostgreSQL 18.6 docs, and it's literally the glow-up your cross-database queries needed. sit down, grab a strawberry πŸ“, and let's get into it.


🌸 NAME 🌸

dblink β€” runs a query in a remote database. that's it, that's the whole vibe. remote queries, but make it a function call. πŸ’–


✨ 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 whole flavors, pick your icon era πŸ‘‘


πŸ¦‹ DESCRIPTION πŸ¦‹

so dblink executes a query in a remote database. usually that's a SELECT, but honestly it can be any SQL statement that returns rows. no cap.

and the way it picks where to go β€” this is the part people get confused about, so listen up 🫢:

  • when you give it two text arguments, the first one gets looked up as a persistent connection's name first.
  • if it's found? the command runs on that connection. slay, easy.
  • if it's not found? that first argument gets treated as a connection info string, exactly like for dblink_connect, and the connection it makes only exists for the duration of this one command. temp connection, main character energy for one scene only πŸ’€

πŸŽ€ ARGUMENTS πŸŽ€

  • connname β€” the name of the connection you wanna use. omit this one entirely if you want the unnamed connection. it's giving "i didn't pick a favorite" πŸ™ˆ
  • connstr β€” a connection info string, as previously described for dblink_connect. literally the same thing you already know and love.
  • sql β€” the SQL query you want executed in the remote database. for example select * from foo. keep it cute, keep it valid ✨
  • fail_on_error β€” if it's true (which is the default when you omit it, jsyk) then an error thrown on the remote side of the connection causes an error to also be thrown locally. if it's false, the remote error gets locally reported as a NOTICE instead, and the function returns no rows. so like, it just politely tells you and moves on. no drama, no crash πŸ’…

πŸ’– RETURN VALUE πŸ’–

it returns the row(s) the query produced. and because dblink can be used with any query, it's declared to return record rather than specifying any particular set of columns. which is iconic of it, but also means you have to specify the expected set of columns in the calling query β€” otherwise PostgreSQL would have no idea what to expect. it's not psychic, bestie.

here's the 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%';

so the "alias" part of the FROM clause must specify the column names and types 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 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. pre-planning, queen behavior.

at run time, an error gets thrown if the actual query result from the remote database doesn't have the same number of columns shown in the FROM clause. but β€” and this is the plot twist β€” the column names need not match. and dblink doesn't insist on exact type matches either. it'll succeed so long as the returned data strings are valid input for the column type declared in the FROM clause. lowkey forgiving, highkey iconic πŸ”₯


🌈 NOTES 🌈

a convenient way to use dblink with predetermined queries is to create a view. this lets all that column type information be buried in the view instead of having to spell it out in every single query. your wrists will thank you. 🫢

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%';

see how clean that is? obsessed. 😭


⭐ EXAMPLES ⭐

first up, the direct call, no connection name, connection string inline:

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)

okay now let's make a connection so we don't have to keep passing the connstr around, periodt:

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

and now we can just hit the unnamed connection like it's nothing:

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)

now bestie, let's do a named connection. give it a little pet name, it deserves one:

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

and here's the payoff β€” different database (regression, not postgres), so the row count is different too. notice it πŸ‘€:

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)
not me counting the rows to make sure it's 14 and not 12 😭 the myconn one is genuinely bigger. ate. πŸ’…

and that's the whole page, no skips, no shortcuts. this was PostgreSQL 18.6, dated 2026, and it's the DBLINK(3) manual page. go run a remote query, you gorgeous genius πŸ¦‹βœ¨ bye bestie πŸ’–