"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > On 10/26/06, Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly