Skip to content

Don't use prefix import as it breaks in old nodes. #3578

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
brianc merged 2 commits into from
Jan 15, 2026
+5 −5
Merged

Don't use prefix import as it breaks in old nodes. #3578

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1400556
Don't use prefix import as it breaks in old nodes. This is a one time…
brianc Jan 14, 2026
dbc0bc7
Update docs
brianc Jan 14, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions docs/pages/guides/upgrading.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,10 @@ title: Upgrading
slug: /guides/upgrading
---

## node version support

I have maintained legacy apps in production for many years. I get it...upgrading node and your entire dependency tree is rough, but so is missing out on critical fixes. I've taken pride over the years in not introducing breaking changes without a need because I've spent too much of my own time in my own apps upgrading a semver major version of a library with many breaking changes. That being said: node-postgres only _officially_ supports node versions which are still under the [LTS lifetime](https://nodejs.org/en/about/previous-releases). The [CI matrix](https://github.com/brianc/node-postgres/blob/master/.github/workflows/ci.yml#L39) is the most official and enforced compatiblity matrix; however, I may drop support for node versions outside of node's LTS lifetime at any time, with any semver minor release, if it is required to land new features or bug fixes on supported versions of node. I recommend in general to use a lockfile, and, if you're on an older version of node nearing EOL use absolutely pinned versions for as many of your modules as you can, including this one.

# Upgrading to 8.0

node-postgres at 8.0 introduces a breaking change to ssl-verified connections. If you connect with ssl and use
Expand All @@ -23,10 +27,6 @@ The rest of the changes are relatively minor and unlikely to cause issues; see [

node-postgres at 7.0 introduces somewhat significant breaking changes to the public API.

## node version support

Starting with `[email protected]` the earliest version of node supported will be `[email protected] LTS`. Support for `[email protected]` and `[email protected]` is dropped, and the module wont work as it relies on new es6 features not available in older versions of node.

## pg singleton

In the past there was a singleton pool manager attached to the root `pg` object in the package. This singleton could be used to provision connection pools automatically by calling `pg.connect`. This API caused a lot of confusion for users. It also introduced a opaque module-managed singleton which was difficult to reason about, debug, error-prone, and inflexible. Starting in [email protected] the methods' documentation was removed, and starting in [email protected] the methods were deprecated with a warning message.
Expand Down
2 changes: 1 addition & 1 deletion packages/pg/lib/client.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

const EventEmitter = require('events').EventEmitter
const utils = require('./utils')
const nodeUtils = require('node:util')
const nodeUtils = require('util')
const sasl = require('./crypto/sasl')
const TypeOverrides = require('./type-overrides')

Expand Down