Conversation

aqeelat

When this pr is merged, we can update @types/pg to not depend on @types/pg-types

@brianc

pg-types @ 4.x is not backwards compatible, so it requires a major version bump (and a LOT of headache for library consumers)

@brianc

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.

@aqeelat

@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?

@aqeelat

Oh I just came across brianc/node-pg-types#50 and the PRs related to it.
Should I convert this into a discussion?

@aqeelat

From what I can gather:

  1. 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.
  2. postgres DATEs will be returned as string

But yeah, this should be a major version bump

@brianc

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.

@abenhamdine

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.

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

@brianc is there a anything I can do to help?

@brianc

@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.

@aqeelat

Sign up for free to join this conversation on . Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.