I was thinking about the proposals that have been made a couple of times
to offer a variant of VACUUM that works by table-rewriting (ie, same as
CLUSTER except for not sorting the rows). I thought I'd do some
experimentation to see what a reasonable syntax for it would be.
I soon convinced myself that there's no way to extend the existing
VACUUM syntax (modifier keywords after "VACUUM") without making the
new modifier keyword at least partly reserved. The counterexample for
an unreserved modifier is that it'd be ambiguous whether "VACUUM FOO"
means vacuum with the FOO modifier or vacuum a table named "foo".
If we go this route, the best choice of modifier seems to be REPLACE,
because (1) that's at least somewhat connected to what the command would
do, and (2) REPLACE is called out as a <reserved word> by SQL99, so we
could defend ourselves against complaints by pointing to the spec.
I verified that bison will take this syntax if REPLACE is promoted to
type_func_name_keyword. (We don't want to promote it all the way to
reserved_keyword, because that would break the built-in replace()
function.)
However, particularly in view of some of the ideas that have been kicked
around for changing VACUUM's behavior to exploit map-fork data, maybe it
is time to bite the bullet and clean up VACUUM's syntax so that new
modifiers can be added without making them reserved words. The first
idea that comes to mind is something like
VACUUM [tablename] [ WITH REPLACE, VERBOSE [, ...] ]
Of course we'd continue to support the old syntax for awhile, but it
would never include any more options than it has today; and perhaps
someday we'd eliminate it and be able to downgrade VERBOSE and friends
to unreserved keywords.
Comments, better ideas?
regards, tom lane
PS: a note for anyone trying to implement this: I checked that bison
would accept the following additional productions for VacuumStmt:
| VACUUM opt_full opt_freeze opt_verbose WITH vac_opts
| VACUUM opt_full opt_freeze opt_verbose qualified_name WITH vac_opts
;
vac_opts: vac_opt | vac_opts ',' vac_opt
;
vac_opt: REPLACE | FULL | FREEZE | VERBOSE | ANALYZE
;
The opt_full and so on are icky but you get shift/reduce problems
without 'em. We could accept the old options there, or throw error
in the action if any are specified along with a WITH-list.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
