So I gave up waiting for someone else to do the reloptions patch for autovacuum and started work on it myself. What I soon discovered is that on first blush it seems a lot easier than I had expected.
On second look, however, the problem is that I seem to be forced to declare all the autovacuum-related options and their parsing properties in reloptions.c. This seems very ugly. I'd very much prefer to be able to declare the options in autovacuum.c and let the rest of the code just ignore them. However, parseRelOptions seems inclined to barf about options it doesn't know about. Maybe that's fine with the current usage, but I think it would be better to leave the options in StdRdOptions alone, and have the autovacuum options defined elsewhere, which seems to require an API change to parseRelOptions -- though I'm not sure what's appropriate. AFAICS this is completely uncharted territory -- the current code understands only fillfactor as a valid option. If we were down the route of just adding the new options just like fillfactor is currently dealt with, the API would get really ugly very quickly. It seems to me we should provide a way to "register" valid options, so that autovacuum.c could inform reloptions.c what are the valid keys that a normal option parsing should just ignore (and, conversely, what options should it ignore when parsing for autovacuum). Thinking more about it, it seems to me that the treatment that fillfactor currently gets should be ripped out in favor of being registered too, somehow ... Before we waste too much time thinking how this registering is to be done, does anybody think that the current approach is OK and thus I should just add the autovacuum options directly into StdRdOptions and default_reloptions? -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ "El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte" (Ijon Tichy en Viajes, Stanislaw Lem) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
