Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pgdiff as a library #44

Open
achew22 opened this issue Jun 9, 2020 · 3 comments
Open

pgdiff as a library #44

achew22 opened this issue Jun 9, 2020 · 3 comments

Comments

@achew22
Copy link

achew22 commented Jun 9, 2020

I was thinking about using pgdiff as part of my deployment and migration pipeline. The pipeline is already written in go and I was curious if there would be any appetite for making pgdiff into a library. Before I put in the effort to do it I wanted to ask, would you be receptive to making the package importable?

@joncrlsn
Copy link
Owner

joncrlsn commented Jun 9, 2020

Hi Andrew, that would be pretty cool and I don't think it would be too hard. Create a pull request and I'll take a look at it.

@joncrlsn
Copy link
Owner

joncrlsn commented Jun 14, 2020

Hi Andrew, I was thinking more about this. If you fork this this into a library that you manage and maintain, I would port my front-end to use your library, and let people know that it is using your library. (Or if you wanted to maintain the command-line interface as well, I would change the README to point people to your project).

I don't have as much of a reason to maintain this code anymore, so you would actually be doing the community a favor by giving it some attention. And I'm very interested in keeping the project useful for others even if I don't have the time or energy I once had for it.

Maybe that's more than you wanted to take on, but I thought I'd suggest it for the good of the community.

@facefunk
Copy link

facefunk commented Jun 28, 2022

Hi,

With the same motivation as achew22, I have taken a stab at libraryfying pgdiff here, if anyone is still interested.

I'm also planning to refactor Schema object instantiation using the abstract factory pattern to allow different data sources. Eventually I'd like to be able to parse SQL create statements directly and cut the DB round-trip from the pipeline altogether.

Out of interest, joncrlsn; is the reduced reason to maintain this project you mention due to finding a better method for maintaining Postgres DB schema versions or have you just found that you don't need to do so as much any more?

Thanks!

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

No branches or pull requests

3 participants