Updating to the newest version of pg-types

[mwanago]

Currently, the pg library uses a very old version of pg-types.

Is there something, in particular, that is stopping us from updating to the newest version of the pg-types library?

[mwanago]

@brianc What do you think?

[brianc]

I think there are some backwards incompatible changes but I'm fine to do a semver bump and up the version of pg types. I'll start looking into this.

[sgronblo]

I just noticed that we would need the latest version of pg-types to work with date without having it turn into mangled Javascript dates. @brianc were you able to take a look into what those breaking changes would be?

[charmander]

@sgronblo You can always override the date parser before pg-types is upgraded, note.

[hpohlmeyer]

Are there any plans on how to proceed? The old pg-types parses timezone-less timestamps in the system timezone, while the new one parses it as UTC date. One could argue what the right behavior would be, but since most people set their database timezone to UTC it seems to be an improvement. Further proof for that would be sequelize/sequelize#3000, which would also be fixed by updating pg-types in pg.

For now, I could work around this using npm overrides to force pg to resolve to the latest pg-types package.

"overrides": {
  "pg": {
    "pg-types": "^4.0.1"
  }
},

[nwalters512]

I'd love to see this happen to pick up the new version of postgres-interval that was introduced in brianc/node-pg-types#126!

[tleiroblox]

the old postgres-date also have some serious performance issues which was mitigated in bendrucker/postgres-date#21, any plan to continue work on this?

[charmander]

@tleiroblox Was there some kind of pathological date case that I missed? 3x speedup on parsing doesn’t sound like “serious performance issues”.

[tleiroblox]

@tleiroblox Was there some kind of pathological date case that I missed? 3x speedup on parsing doesn’t sound like “serious performance issues”.

For time series data that has date in every row, parseDate old implementation alone could easily cost more than 50% of the cpu cycles pg used, which often become the bottleneck of the whole node application. It's also not memory efficient that can result in more gc (which also lead to cpu usage)