Re: Eliminating phase 3 requirement for varlen increases via ALTER COLUMN

"Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
> On 10/26/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> This makes some really quite unacceptable assumptions about
>> the meaning and encoding of typmod ...

> True, so VARCHAR seems like the only one? That's the only one I've
> really encountered in the field on a fairly regular basis.

Well, you could either hardwire some specific cases for specific types
here, or think about inventing a general-purpose mechanism that would
let types register a function to report whether a given typmod change
requires actual work. I'm not sure it's worth the latter though.

One point worth thinking about is that varchar(any) --> text could be
a "free" coercion too, along with cases such as replacing a domain
by its base type. I think we can detect this today by the
expedient of noting whether the coercion ends up being just a
RelabelType expression --- I'm actually a bit surprised that that
knowledge doesn't seem to be in the code already.

OTOH ... RelabelType means the bits are the same but it doesn't imply
that the semantics of the bits are the same, eg, OID has a different
sort order than int4. So ISTM that in general it'd still be necessary
to recheck constraints and rebuild indexes. This might be a sufficient
reason for limiting the optimization to a few known-safe cases like
varchar/text, rather than trying to do it for any binary-compatible
conversion.

Another thought is that some cases would amount to checking constraints
but not changing any bits on-disk, as in replacing a base type with a
domain. Is it worth having these go through the non-rewriting code
path? How would we be sure we didn't need to rebuild indexes?

regards, tom lane