After a long battle with technology, josh@agliodbs.com (Josh Berkus), an earthling, wrote:
>> As long as pg_autovacuum remains a contrib module, I don't think
>> any changes to the system catelogs will be make. If pg_autovacuum
>> is deemed ready to move out of contrib, then we can talk about the
>> above.
>
> But we could create a config file that would store stuff in a
> flatfile table, OR we could add our own "system table" that would be
> created when one "initializes" pg_avd.
The problem with introducing a "config file" is that you then have to
introduce a language and a parser for that language.
That introduces rather a lot of complexity. That was the BIG problem
with pgavd (which is a discarded project; pg_autovacuum is NOT the
same thing as pgavd). There was more code involved just in managing
the pgavd parser than there is in all of pg_autovacuum.
I think the right answer for more sophisticated configuration would
involve specifying a database in which to find the pg_autovacuum
table(s).
> Just an idea. Mind you, I'm not so sure that we want to focus
> immediately on per-table settings. I think that we want to get the
> "automatic" settings working fairly well first; a lot of new DBAs
> would use the per-table settings to shoot themselves in the foot.
> So we need to be able to make a strong recommendation to "try the
> automatic settings first."
Yeah, it's probably a good idea to ensure that per-table settings
involves some really conspicuous form of "foot gun" (with no kevlar
socks) to discourage its use except when you _know_ what you're
doing...
--
let name="cbbrowne" and tld="ntlug.org" in String.concat "@" [name;tld];;
http://www3.sympatico.ca/cbbrowne/nonrdbms.html
Q: Can SETQ only be used with numerics?
A: No, SETQ may also be used by Symbolics, and use it they do.