On Sat, Jun 12, 2021 at 4:29 AM Julien Rouhaud <rjuju...@gmail.com> wrote:
> I'd like to propose an alternative approach, which is to allow multiple > parsers > to coexist, and let third-party parsers optionally fallback on the core > parsers. I'm sending this now as a follow-up of [1] and to avoid duplicated > efforts, as multiple people are interested in that topic. The patches all build properly and pass all regressions tests. > pg_parse_query() will instruct plugins to parse a query at a time. They're > free to ignore that mode if they want to implement the 3rd mode. If so, they > should either return multiple RawStmt, a single RawStmt with a 0 or > strlen(query_string) stmt_len, or error out. Otherwise, they will implement > either mode 1 or 2, and they should always return a List containing a single > RawStmt with properly set stmt_len, even if the underlying statement is NULL. > This is required to properly skip valid strings that don't contain a > statements, and pg_parse_query() will skip RawStmt that don't contain an > underlying statement. Wouldn't we want to only loop through the individual statements if parser_hook exists? The current patch seems to go through the new code path regardless of the hook being grabbed.