Robert Haas <robertmh...@gmail.com> writes: > On Dec 29, 2010, at 11:16 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I really really dislike the notion of a "verification scan": it's >> basically work that is going to be useless if it fails.
> I think it has potential in cases like text to xml. In that case it'll > either work or fail, with no possibility of requiring a do-over. Scanning > the whole table is a whole lot cheaper than rewriting it. I don't believe avoiding the write part (but not the read part, nor the XML syntax verification part) is a sufficiently compelling argument to justify having that code path. There are not enough distinct datatypes sharing binary representations to make this a worthwhile thing to worry over. Basically, I believe that the only use-case that will have more than epsilon number of users is "I want to make this varchar(5) into varchar(10), or possibly text". We can fix that case without adding a boatload more code that we'll have to maintain. I do have some interest in the idea of having a type-specific function that can recognize no-op typmod changes, but I would envision that as being an expression evaluation optimization: let the planner throw away the call to the length-checking function when it isn't going to do anything. It's not by any means only useful in ALTER COLUMN TYPE --- and in fact probably doesn't even need any bespoke code there, if we put it into expression_planner() instead. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers