On Sat, 2009-11-14 at 19:25 -0500, Tom Lane wrote:
> As a rule of thumb, I'd recommend keeping as much complexity as possible
> *out* of gram.y. It's best if that code just reports the facts, ie what
> options the user entered. Deriving conclusions from that (like what
> default behaviors should be used) is best done later. One example of
> why is that if you want the defaults to depend on GUC settings then
> that logic must *not* happen in gram.y, since the parse tree might
> outlive the current GUC settings.
I was referring to (in vacuum()):
+ if (vacstmt->options & (VACOPT_INPLACE | VACOPT_REPLACE |
VACOPT_FREEZE))
+ vacstmt->options |= VACOPT_VACUUM;
+ if (vacstmt->va_cols)
+ vacstmt->options |= VACOPT_ANALYZE;
I think what you say applies to VACOPT_ANALYZE, which is implied when
columns are supplied by the user but ANALYZE is not specified
explicitly. In that case it should be set in vacuum() but not in gram.y
(unless specified by the user).
However, for VACOPT_VACUUM, I think that's still in the territory of
gram.y.
Regards,Jeff Davis