Windows Support

[lfittl]

Issue to track support of Windows - currently it is not supported, in part due to build process, in part because the code extraction from Postgres intentionally ignores Windows code.

[Corion]

I did look at making it build on Windows, but besides adding some more -DDEFINEs and some stubs, I haven't progressed far. I think the general approach is to fake as much of the "normal" Pg environments to get the code to compile without any changes to the Pg code at all, but I don't understand why the files are copied during the build process.

Can you maybe outline a bit what the general approach is? I have the rough idea that you implemented a preprocessor that rewrites/copies the C files according to some preset #defines, but a bit more detail would help me get more of the general approach.

[lfittl]

@Corion The general approach taken is that code is extracted using LLVM/clang (plus a Ruby helper script), see https://github.com/lfittl/libpg_query/blob/10-latest/scripts/extract_source.rb

That means the code that gets extracted is partially dependent on the environment where the extraction runs, as well as the defines passed to clang: https://github.com/lfittl/libpg_query/blob/10-latest/scripts/extract_source.rb#L205

My general thoughts on how to make progress on this:

• Remove the explicit ignores of Windows build files in https://github.com/lfittl/libpg_query/blob/10-latest/scripts/extract_source.rb#L97
• Try to build, and compile a list of places where we error out right now
• Manually adjust defines and try to fix things to the point where we know what changes are needed (and ideally things build and don't crash)
• Re-introduce the changes needed to the extraction script, so we can re-run it for new Postgres versions without issue

[Corion]

I've pushed my (really hacky) changes that I needed to make some progress on Windows as https://github.com/Corion/libpg_query/tree/win32-hackery . I think parts of my lack of progress can be attributed to the simply missing build files for Win32, but I'm not sure if the source code really has that many OS dependencies.

I think at least the second point ("list of places where we error out") should be somewhat reduced with the changes in the win32-hackery branch. Please note that I approached the issue strictly with the mindset of "anything that's necessary to get this to compile", not with the mindset of understanding things or finding a nice/maintainable solution. So cherry-picking patches is not really advised except for maybe the parts where a #define was hacked.

[lfittl]

@Corion Nice, thanks for sharing!

Its a priority for me to make progress on this, however there is a few other things on my plate too unfortunately. I'll update here with any progress I make as well to keep you and others in the loop.

[akeeman]

Any progress?

[lfittl]

@akeeman Not yet - thanks for checking!

I'm curious, whats your use case for the library on Windows?

[akeeman]

A few of my colleagues are working on windows, and run some code on their local machine outside of their Docker container on a schedule. All the other code is platform independent, so before it was fine to do so.

We use this library via pglast to extract the tables given a query. During tests it's for dynamically only inititalizing those tables used in the test during integration tests. Besides that it's for automatically locking tables we write.

[amhuhn2]

Hi, @lfittl any progress here?

Here's my use case: I use Windows as my development workstation, although eventually this will be deployed to Heroku, running on some flavor of Linux. But while I am developing the code, I'd like to be able to run it locally to test/develop.

I need to parse a view so that I can walk the parse tree and attempt to figure out which rows are dependent on a row currently being updated.

Thank you for your hard work to maintain such a useful package! I can't wait to start using it.

[lfittl]

@amhuhn2 Nothing to report yet, but thanks for the additional context of your use case - that is helpful to know.

I may be able to take some time to work on this in the upcoming weeks, and will certainly update this issue as I get closer to making this a reality. Thanks for your patience!

[amhuhn2]

Sounds good, @lfittl , thank you.

[runfaj]

@lfittl Any progess on this? In our use case, we use pg-query-parser for our package for building dynamic AST queries in node. pg-query-parser relies on pg-query-native, which in turn, relies on this package.

Because this package doesn't have windows support, some of the build symbols for the other packages fail, thus making the whole project to fail install. All of our team works on macs, where this package works, but in order to allow windows development, this is the only package out of hundreds that ends up preventing it.