Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> writes:
> Mark Stosberg wrote:
>> Adding a default of -1 seems like a more cumbersome way to express the
>> same thing to me.
> To be frank, I don't remember what the rationale was for not using
> NULLs. Simplicity of code, I guess.
We tend to avoid allowing fixed-size fields to be NULL in the system
catalogs, because it prevents using the technique of overlaying C
structs onto the catalog tuples. In fact, if you wanted to have any
null fields in pg_autovacuum, you would need to find a way to prevent
initdb from enforcing that policy:
regression=# \d pg_autovacuum
Table "pg_catalog.pg_autovacuum"
Column | Type | Modifiers
------------------+---------+-----------
vacrelid | oid | not null
enabled | boolean | not null
vac_base_thresh | integer | not null
vac_scale_factor | real | not null
anl_base_thresh | integer | not null
anl_scale_factor | real | not null
vac_cost_delay | integer | not null
vac_cost_limit | integer | not null
freeze_min_age | integer | not null
freeze_max_age | integer | not null
Indexes:
"pg_autovacuum_vacrelid_index" UNIQUE, btree (vacrelid)
I don't find this particularly important, because we have never intended
direct update of catalog entries to be a primary way of interacting with
the system. The current pg_autovacuum setup is a stopgap until the dust
has settled enough that we know what sort of long-term API we want for
autovacuum.
regards, tom lane
