Peter Eisentraut <peter_e@gmx.net> writes:
> The SQL standard requires conforming implementations to provide an
> "SQL flagger" facility ...
> I think we could implement this with relatively little intrusion if we
> create an interface routine, say SQLFlagger(), which takes the entire
> parsetree as its argument can then analyze the syntax in as much
> detail as it likes. (Of course that function would only be called if
> a certain Boolean flag is set.) But a few syntax elements would need
> to checked right within gram.y, such as the omission of the drop
> behavior or the use of TEMP vs. TEMPORARY, which is resolved right in
> the parser and cannot be detected later.
> Should we implement this?
I think we would be better off to implement this as a standalone program
rather than as a backend mode option.
In general, gram.y's behavior should never depend on any runtime
variables. If it does, you get inconsistent results fromSET var = val ; ... other stuff ...
(one query string) compared toSET var = val... other stuff ...
(two query strings), because the whole query string is fed through
gram.y before any of it is executed.
Plan B, if you really want to do this in the backend, would be to alter
gram.y's output trees so that all the non-spec constructs are still
recognizable in the raw parse tree, and any conversions needed are done
in analyze.c's processing (which would also be the place to issue the
flagger warnings). This is not necessarily a bad idea; I've always
thought that we do too much work in gram.y anyway. But you will be
fighting a permanent rear-guard action to keep people from
re-introducing variant syntaxes by quick gram.y hacks.
In general I like the idea of a standalone program better, however.
It would be able to have its own grammar tuned to its needs. I don't
think there would be much maintenance problem introduced thereby,
since presumably the flagger's grammar is driven by the spec and won't
need to change when we change what Postgres accepts.
regards, tom lane
