DeprecationWarning: Buffer() is deprecated due to security and usability issues

[harry-chin]

└─┬ pg@8.5.1
└─┬ pg-types@2.2.0
└── postgres-bytea@1.0.0

This issue is happening because of using old version of pg-types module.
Do you have a plan to update pgtypes to 3.x from 2.x?
The latest version of pg-types is using new version of postgres-bytea and this issue has been fixed there.

[brianc]

Oh yes I need to upgrade. I know there are some backwards incompatible changes which is why I've waited so long. I think I should schedule a pg@9.0 upgrade for some time in January and make it a bundle of breaking changes. @charmander got any other breaking changes that come to mind? I'd like to deprecate the "query queue" concept in 9.0 - add a deprecation warning if you queue a query while another one is still in flight. Thoughts?

[charmander]

@brianc All of that sounds good! BigInt becoming the default value type for BIGINT is also something pg-types might be about to get. If you’re looking to bundle more breaking changes (I guess it’s good for getting people to look at the changelog!), thoughts on these?

• No type-parsing defaults, meaning an unknown OID is an error instead of a string (or a binary buffer)?
• Splitting the overloaded types query option (it’s an array of OIDs, but also a TypeParser) into incoming and outgoing types
• Fully libpq-compatible connection string parsing (started at https://github.com/charmander/libpq-connection-string), with the key=value syntax + multiple hosts + matching sslmode=… behaviour (sslmode=require in connection string breaks with self signed certificate #2375, Fix 'Error: invalid sslmode value: "true"' in native mode #2299) + service configuration (service= connection parameter #416)
  • this one needs a deprecation step for things like ssl=1 and Add PGSSLMODE=no-verify support to opt-out of rejecting self-signed certs #2195

We can open issues to discuss them if they sound worth talking about!

Also, for pg-pool, there are breaking change ideas queued up, like returning client wrappers that stop working when they’re returned to the pool; those would also be waiting on a new major pg version eventually, so maybe they can be revisited too for this major.

[charmander]

@vitaly-t Your “generic” package isn’t libpq-compatible. It’s MongoDB-compatible. release(true) is completely unrelated to what you quoted and I don’t feel like wasting time expanding on it for you.

[RichardBradley]

Is there any update on this? We get this warning on all our Lambda invocations and it's quite noisy.

How is the proposed upgrade to pg@9.0 progressing? Is there an issue I can follow for updates on that?

Does anyone know of a workaround? Would it be practical to update the 2.x branch of pg-types to update its postgres-bytea without doing the full pg@9 update for node-postgres, if that is not expected soon?

[thmang82]

Any plans to fix this?
Whenever BYTEA is used on a node:lts image (node 18), I get an error log. Not so nice :-(

[70nyIT]

Want to do a bump in this. We've our monitor system flooded with console.error reporting this error, since we're using BYTEA a lot. Any chance to have this upgraded?

[danny-hunt]

Hey this issue is causing crashes for me (although due to an obscure & annoying mesh of dependencies that isn't really pg's fault). There is a bug in some versions of node: nodejs/node#53075 that mean that the Buffer() deprecation warning instead crashes in WASM environments.

I'm using vercel (whose current node version (20.15.X) is currently vulnerable to the above bug and neondatabase that uses pg as a dependency.

Is there any idea when this might get addressed? I'll probably be looking for alternative solutions on my end anyway but thought it was worth bumping

[charmander]

@danny-hunt You can add the newer version of pg-types as a dependency, then pass it to pg as the types property of the config.

[fedecastelli]

Hi there!

While I wait for a new release to fix how BYTEA is handled in node, I added these lines of code to my pg client initialization:

import PG from 'pg';

PG.types.setTypeParser(PG.types.builtins.BYTEA, function (value: string) {
  return value ? `0x${value.slice(2)}`.toLowerCase() : null;
});

This change prevents an error from being logged every time a BYTEA is read. I hope this helps!

[charmander]

Also a good workaround. If you want to be compatible with the defaults, it’s

PG.types.setTypeParser(PG.types.builtins.BYTEA, (value: string) => Buffer.from(value, 'hex'));