pgparser reports a false insert-without-columns on INSERT ... DEFAULT VALUES #68

Problem

parsers/pgparser resets InsertColumnsListed = false and refills it from
len(n.Columns) > 0. INSERT INTO t DEFAULT VALUES has no column list and
needs none — the zero-dependency fallback handles this explicitly
(analyzer/fallback.go, "DEFAULT VALUES inserts no data"). The AST path
discards that and then sets Exact = true over it.

INSERT INTO t DEFAULT VALUES
  fallback findings: []
  pgparser findings: [insert-without-columns]

Verified on main today. mysqlparser is unaffected — vitess normalises
INSERT ... SET into columns, and MySQL has no DEFAULT VALUES form.

Impact

Opting into the "exact" parser makes this rule strictly worse than the
default, which inverts the trade-off website/docs/parsers.md describes.

Related, lower-impact

Both dialect parsers blank all eight structural fields up front and only
refill them for Select/Delete/Update/Insert. Any other AST node (DDL,
SET, transaction control) keeps Exact = true with every structural flag
forced false, discarding the fallback's values. Today that only costs
orderby-without-limit on non-DML — a false negative, so it fails safe — but
the reset-then-partially-refill shape will bite the next rule that reads a
structural field outside those four kinds.

Direction

Treat the fallback's value as the baseline for InsertColumnsListed and only
overwrite when the AST is authoritative, or special-case DEFAULT VALUES.
For the broader issue, move the field resets inside each case.

Acceptance criteria

• INSERT INTO t DEFAULT VALUES produces no insert-without-columns finding
  under pgparser.
• A parity test asserting the dialect parsers never add a finding the
  fallback does not produce for the same input.