On Wed, May 15, 2024 at 1:00 PM Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, May 15, 2024 at 3:28 PM Tom Lane <t...@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.
