Lukas Fittl

> @lfittl it's the `planetscale` org. If you can extend the trial, I can get this tested with some real data. Done - extended it until end of January for...

> And some other issues related to warnings and errors as well. Thanks for the report - unfortunately it looks like you skipped the part of the output that was...

Hi @Dtenwolde, Thanks for opening the issue and inquiring on this! Any addition to the grammar that is specific to libpg_query (vs upstream Postgres) has to be viewed in light...

Thanks for reaching out! In my understanding adding custom operators doesn't actually modify the parser - just the parse analysis process that operates on the raw parse output. Since libpg_query...

> The explicit feature ask would then be the tree at `Plan` time, i.e. the [`PlannedStmt` node representation](https://github.com/postgres/postgres/blob/89372d0aaa4a6f0e560acdf9014c5ad66fdde1b1/src/include/nodes/plannodes.h#L46). Makes sense! That is not something we are planning to add to...

Thanks for the PR! I think that makes sense, but it appears we'd have to raise the `go.mod` version to allow using the newer syntax (see https://github.com/pganalyze/pg_query_go/actions/runs/17171245591/job/49052448270?pr=139). Maybe that's reasonable...

Thanks for reaching out! To capture my understanding: - The main use case here is statement splitting - You're looking to recover better from errors, so the parser is not...

> Hi, I have some interest in this functionality and am using a fork. Is this PR likely to be merged more-or-less in its current form? Good question! I've been...