Re: pg_autovacuum should allow NULL values

Alvaro Herrera <alvherre@commandprompt.com> 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