| ▲ | ZiiS 3 months ago | ||||||||||||||||
Tends to be a matter of opinion. Postgres does not expose the relevant functions, so https://github.com/pganalyze/libpg_query has to do some heavy lifting to convert their source code into a nice library. Conversely, Postgres is very well written code, in an extremely common language, with a stable release cadence, and such a long track record it is seen as the reference implementation for correctly parsing SQL. | |||||||||||||||||
| ▲ | lfittl 3 months ago | parent [-] | ||||||||||||||||
Yeah, as one of the main authors of libpg_query, I think the primary things that make this easier is that Postgres has good abstractions internally, and the parser works independently from other parts (e.g. the community discourages adding settings that affect parser behavior). Over the years we've only had to maintain a small set of patches on top of the Postgres source [0], together with some mocks and our libclang-based extraction logic [1]. Of course it would be nice if Postgres just packaged this directly like it packages the client libraries, but there is non-trivial effort involved to do that. From what I recall, the main issue is that error handling and memory allocations work differently in the client-side libraries (and so that would have to either also be moved out of the backend source, or use some other abstraction). [0]: https://github.com/pganalyze/libpg_query/tree/17-latest/patc... [1]: https://github.com/pganalyze/libpg_query/blob/17-latest/scri... | |||||||||||||||||
| |||||||||||||||||