brianc
dep: upgrade pg-types to ^4
When this pr is merged, we can update @types/pg to not depend on @types/pg-types
pg-types @ 4.x is not backwards compatible, so it requires a major version bump (and a LOT of headache for library consumers)
I think there needs to be another fork or something of pg-types that does not do the date/time zone conversion differently. Unfortunately changing that would be insanely breaking for a lot of deployed code-bases even though the original decision 15 years ago wasn't the best....I'm not convinced its worth the forced upgrade there.
@brianc can you elaborate on what that means?
Also, does it make sense to use pg-types without node-postgres? If not, then why not move the source code for that library into this repo and tie their development together?
Oh I just came across https://github.com/brianc/node-pg-types/issues/50 and the PRs related to it. Should I convert this into a discussion?
From what I can gather:
- the Date objects will now be parsed to the current timezone even if they do not have timezone in them (which is why the test is failing). To fix this test, we could retrieve the timezone of the db connection and then add the offset.
- postgres DATEs will be returned as string
But yeah, this should be a major version bump
But yeah, this should be a major version bump
I am leaning towards re-absorbing pg-types in some form into this monorepo & before incorporating it, reverting the breaking changes to the date parsing. Then it can be more tightly versioned w/ the rest of the code, benefit from the years of perf tweaks done to the stand alone pg-types library, and not cause massive, hard to catch breaking changes like what would happen if i just bumped pg-types in this library.
I am leaning towards re-absorbing pg-types in some form into this monorepo & before incorporating it, reverting the breaking changes to the date parsing. Then it can be more tightly versioned w/ the rest of the code, benefit from the years of perf tweaks done to the stand alone pg-types library, and not cause massive, hard to catch breaking changes like what would happen if i just bumped
pg-typesin this library.
That's the more reasonable move I think. With a feature flag to enable the change on date parsing, so anyone could try it and start changing its code base for that.
@aqeelat thanks for asking - just getting over the flu...I think the biggest thing that would help, though it's quite a bit of effort, is fork [email protected] and then change it so the existing tests under ./packages/pg pass without any moidifications to the pg codebase. There are tests around the date timezone and date returning an actual date ( I believe) that are failing that need to pass. Basically make a [email protected] that is not a breaking change. Then it'll be really easy to absorb.
