On Wed, Jul 15, 2020 at 02:54:37PM +0200, Magnus Hagander wrote: > Our Fine Manual (TM) specifies: > "As an exception, when changing the type of an existing column, if the > USING clause does not change the column contents and the old type is either > binary coercible to the new type or an unconstrained domain over the new > type, a table rewrite is not needed; but any indexes on the affected > columns must still be rebuilt." > > First of all, how is a non-internals-expert even supposed to know what a > binary coercible type is?
The manual defines it at <firstterm>binary coercible</firstterm>. > We can also for example increase the precision of numeric without a rewrite > (but not scale). Or we can change between text and varchar. And we can > increase the length of a varchar but not decrease it. > > Surely we can do better than this when it comes to documenting it? Even if > it's a pluggable thing so it may or may not be true of external > datatypes installed later, we should be able to at least be more clear > about the builtin types, I think? I recall reasoning that ATColumnChangeRequiresRewrite() is a DDL analog of query optimizer logic. The manual brings up only a minority of planner optimizations, and comprehensive lists of optimization preconditions are even rarer. But I don't mind if $SUBJECT documentation departs from that norm.
