Lukas Fittl

Thanks for your patience on this one!

@MGorkov Thanks for reaching out! This style of writing a function only works for SQL functions, not PL/pgSQL. The `pg_query_parse_plpgsql` function is intended to be used for parsing PL/pgSQL, and...

Thanks for the patch, and conceptually looks good! However it appears there is a problem with the `protobuf-cpp` tests here, blocking a merge. I believe this is actually a larger...

@MGorkov Thanks for your contributions in this PR! I ended up reworking them a bit and merging them in #263. I did not take all changes, but tried to keep...

@jonluca Thanks for the request! Since you opened this on the collector repository, answering in the context of the data collection: You can exclude queries from being tracked by Postgres...

You can find them upstream in the Postgres parser directory: https://github.com/postgres/postgres/tree/master/src/backend/parser (we make slight modifications to them, see https://github.com/pganalyze/libpg_query/tree/16-latest/patches, but for most use cases that difference shouldn't matter)

I wonder if we need to check for impact of the for loop change in 1.22? see https://tip.golang.org/doc/go1.22#language and https://tip.golang.org/wiki/LoopvarExperiment#my-test-fails-with-the-change-how-can-i-debug-it

As of 3/18/25 we still think this is worth considering, but this no longer applies after recent refactorings - need to rework the PR to make it work again.

Per the earlier comment, `pg_query_parse_plpgsql` is not intended to parse arbitrary SQL (it parses PL/pgSQL function definitions), thus closing this as won't fix.

Thanks for the report! Could you confirm which commands you're running exactly? (`make` in the project root?) Additionally, which distribution are you using? (looks like RHEL7 or CentOS7?)