Closed mlt closed 4 years ago
mlt
commented
4 years ago What is the status of extra tests? I see that some of them fail with benign errors on some PG versions, but overall failed tests change from version to version. I tend to believe that it is not Windows only situation.
hrkuma
commented
4 years ago Thank you for pull request.
What is the status of extra tests? I see that some of them fail with benign errors on some PG versions, but overall failed tests change from version to version. I tend to believe that it is not Windows only situation.
Currently we place the expected files which is confirmed on the latest version. So as you pointed out, it will fail on different versions. If something (PostgreSQL/SQLite output etc.) is changed, we cannot test with single set of expected files.
hrkuma
commented
4 years ago We'd like to review your pull request. However it may take some time for some commits, please be patient. And could you make a single pull request for each different kind of fix?
fix for finalizing of prepared statement I think we can merge this fix if you send a single pull request.
PostgreSQL 13 support As preliminary support, I think we can merge your commits if you make a pure pull request only for 13 support. FYI, as our project we are also in the process of confirmation for 13 support including test porting and bug fixing. However, I think it will take some time to complete.
About Windows support Please wait for us to confirm on Windows because we haven't checked this FDW on Windows so far.
About Automated binary release We will consider this kind of support including whether we choose to release binaries in this project and how we can support. I think that it will take a long time to consider, so please understand.
mlt
commented
4 years ago Sure, I will split and rebase this one. It was just easier for me to see that everything combined works as you can see if you follow the link from my previous post. Binary artifacts are available there as well. However they expire in 6 months. That is why I suggested to use GitHub Releases.
hrkuma
commented
4 years ago Sorry for so long to wait.
Could you exclude AppVeyor CI support (.appveyor.yml) from this pull request ? We confirmed other changes and they are OK for us.
About AppVeyor CI support, At present, maintenance of this feature is difficult for us, so we have decided not to support it. Thank you for suggestions.
mlt
commented
4 years ago I removed AV. I'm surprised though with your decision as it is mostly set and forget while it benefits Windows users tremendously. I hope you'll reconsider it at some point.
hrkuma
commented
4 years ago Thank you for support! I'd like to merge Windows support.
I hope you'll reconsider it at some point.
Yes, we'd like to reconsider it if our situation is changed.
Here are some automated stuff to build the extension against EDB's Windows binaries as well as against PG's git. This addresses already closed #21. Also a couple of minor fixes are included.
I used statically linked sqlite not to carry around sqlite3.dll . Also it is still somewhat tricky to specify a proper platform toolset to match that used by EnterpriseDB's binaries (v140 currently) while using vcpkg as it picks up the latest (v141 for Visual Studio 2017) available for a given installation. Using static build somewhat alleviates this issue. Perhaps the worker image could be changed to use VS 2015 if we want to rely on VCRUNTIME140.DLL instead of static build.
Note that for AppVeyor to be able to push binary artifacts into GitHub's Releases, one must create a GH token for that. I hope it is not too much to ask. Here is how: https://www.appveyor.com/docs/deployment/github/