Question: performance impact of types.arrayParser.create vs direct postgres-array.parse about node-pg-types

[charmander]

It’s unlikely to be a performance issue, but I’m not sure why types.arrayParser.create exists at all. (Backwards compatibility?) postgresArray.parse(val, parseInt) with a dependency on postgres-array is fine.

[jeremychone]

Not sure, it was exported in the "@types/pg": "^7.4.10" so I assumed it was the way to do it (and I had to do some digging). Somehow, creating a function per value parsing felt off, but I agree hard to know if it is a performance issue until it is.

But great, I will use the postgresArray.parse, feels more common.

On a related note, would be great if the pg module could export postgresArray and that the parse be in the @types/pg. Right now there is no @types/postgres-array, not deal breaker, just a little cumbersome to use.

Thanks for the fast response, and for this high quality lib. node-postgres's quality has been critical in our decision to move our "big app" dev to node from Java.

[bendrucker]

I've refactored this library a bit over time. Pulled out some of the larger concepts (e.g. arrays, dates) into their own module. But generally kept the API the same.

You should feel free to depend on postgres-array, that's what I was hoping for when publishing it separately (easier to build custom behavior).

As for performance, I'm hesitant to start picking at anything without benchmarks. You're probably right in this case but it's hard to say what the magnitude of impact would be. I'm open to working on that across the node/pg toolchain at some point.

[jeremychone]

Cool thanks. If you want I and contribute the @types/postgres-array to npm or even better, do a pull request on postgres-array with the type definition. Does not change anything for non typescript users, but removes quite a bit of pain for TS user.

[bendrucker]

do a pull request on postgres-array with the type definition

Please do!

[jeremychone]

@bendrucker Just did the pull request, sorry for the delay.