On Wed, May 15, 2024 at 3:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sorry: "make sense" was a poorly chosen phrase there. What I was
> doubting, and continue to doubt, is that 100% checking of what
> you can check without catalog access and 0% checking of the rest
> is a behavior that end users will find especially useful.
You might be right, but my guess is that you're wrong. Syntax
highlighting is very popular, and seems like a more sophisticated
version of that same concept.
The proposed seems distinctly less sophisticated though would be a starting point.
I think the documentation for --syntax check would read something like this:
postgres --syntax-check={filename | -}
Performs a pass over the lexical structure of the script supplied in filename or, if - is specified, standard input, then exits. The exit code is zero if no errors were found, otherwise it is 1, and the errors, at full verbosity, are printed to standard error. This does not involve reading the configuration file and, by extension, will not detect errors that require knowledge of a database schema, including the system catalogs, to manifest. There will be no false positives, but due to the prior rule, false negatives must be factored into its usage. Thus this option is most useful as an initial triage point, quickly rejecting SQL code without requiring a running PostgreSQL service.
Note: This is exposed as a convenient way to get access to the outcome of performing a raw parse within the specific version of the postgres binary being executed. The specific implementation of that parse is still non-public. Likewise, PostgreSQL doesn't itself have a use for a raw parse output beyond sending it to post-parse analysis. All of the catalog required checks, and potentially some that don't obviously need the catalogs, happen in this post-parse step; which the syntax checking API does not expose. In short, the API here doesn't include any guarantees regarding the specific errors one should expect to see output, only the no false positive test result of performing the first stage raw parse.
David J.
If in core I would still want to expose this as say a contrib module binary instead of hacking it into postgres. It would be our first server program entry there.