Lukas Fittl

> I'm writing my own lexer in a different language, and I want to verify that it is producing correct output :) Now for some tokens I can only verify...

Thanks for opening an issue to track it! Yes, we are (of course 😄) planning to upgrade it - probably in the next 2-3 weeks, time permitting.

@pashandor789 See https://github.com/pganalyze/libpg_query/pull/317 -- there are some outstanding issues that I should be able to resolve over the holidays.

> Should have read [#317](https://github.com/pganalyze/libpg_query/pull/317), it mentions the xlocale issue, hopefully `copyfile.h` is similar. Yeah, I think trying to make this work before the compatibility issue is addressed isn't that...

> For some reason that (still) eludes me, the compilation of `libpg_query` [fails](https://github.com/lelit/pglast/actions/runs/20569888546/job/59074850945#step:5:523) in some CI combo with an undeclared `strlcpy`. Hmm, curious. I'll try to see if I can...

> > Basically the core problem that happens is that libpg_query code is generated from Postgres on a macOS machine > > Speaking of this, have you ever thought about...

> As you can see, the second RawStmt is reported to start at 43, just after the semicolon ending the first SELECT, that is clearly wrong, while all other sub-nodes...

Thanks for reaching out! The C library has the [split functions](https://github.com/pganalyze/libpg_query/blob/17-latest/pg_query.h#L117) for this, which we haven't yet made available in the Ruby bindings. This should be fairly straightforward to do,...

This has been added in 0077294d926403bc8291298dd8ddaf2f3695d45f, which can be accessed through `PgQuery.split_with_parser(query)`

Thanks for opening this issue here! For transparency, I'm currently not in favor of doing this for maintenance reasons, but happy to discuss/consider a bit what it'd take and what...