Skip to content

Conversation

datafoo
Copy link
Contributor

@datafoo datafoo commented Feb 5, 2019

Fixes #20.

@gaslit
Copy link

gaslit commented Oct 14, 2021

May I know the status regarding this PR? Many thanks.

@dvic
Copy link

dvic commented Aug 4, 2022

Not sure what the status of this PR is, but isn't it a better approach to have the migrations shipped (with versions) with the library? Like Oban does for example, e.g., Oban.Migrations.up(version: 11)?

@cdegroot
Copy link

@datafoo are you still interested in this change? If so, I think that @dvic is on the money here, we really should then have some (simple) versioning to run this a bit more transparently than "copy/paste this SQL". But given the minor impact of the change and the somewhat large amount of work involved, maybe not worth the trouble?

(sorry for the late response, we had a maintainer change and a large backlog of work)

@datafoo
Copy link
Contributor Author

datafoo commented Feb 27, 2025

I am still interested, I believe we should use the most appropriate data type. And yes it would be great if we could avoid to run manual SQL statements.

@datafoo datafoo force-pushed the issue-20-timestamp-with-time-zone branch from 6037c58 to 99ba8e4 Compare February 27, 2025 10:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Use timestamp with time zone for timestamp fields in projection_versions

4 participants