[Tom Lane <tgl@sss.pgh.pa.us>]

I wrote:
> I think we need to do more than that.  It's certainly not okay to
> leave catalogs.sgml out of sync with reality.  And maybe I'm just
> an overly anal-retentive sort, but I think that code that manipulates
> tuples ought to match the declared field order if there's not some
> specific reason to do otherwise.  So that led me to the attached.

Pushed that after another round of review.

> ... there are two places that set
> up attcompression depending on
>     if (rel->rd_rel->relkind == RELKIND_RELATION ||
>         rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
> This seems fairly nuts; in particular, why are matviews excluded?

While I've not actually tested this, it seems to me that we could
just drop these relkind tests altogether.  It won't hurt anything
to set up attcompression in relation descriptors where it'll never
be consulted.

However, the more I looked at that code the less I liked it.
I think the way that compression selection is handled for indexes,
ie consult default_toast_compression on-the-fly, is *far* saner
than what is currently implemented for tables.  So I think we
should redefine attcompression as "ID of a compression method
to use, or \0 to select the prevailing default.  Ignored if
attstorage does not permit the use of compression".  This would
result in approximately 99.44% of all columns just having zero
attcompression, greatly simplifying the tupdesc setup code, and
also making it much easier to flip an installation over to a
different preferred compression method.

I'm happy to prepare a patch if that sketch sounds sane.

(Note that the existing comment claiming that attcompression
"Must be InvalidCompressionMethod if and only if typstorage is
'plain' or 'external'" is a flat out lie in any case; *both*
directions of that claim are wrong.)

			regards, tom lane