Hi, Josh Berkus <j...@agliodbs.com> writes: >> The stumbling block has been to identify a reasonably clean way >> of determining which datatype changes don't require a scan. > > Yep. One possibility I'm thinking is supplying a function for each type > which takes two typemods (old and new) and returns a value (none, check, > rebuild) which defines what we need to do: nothing, check but not rebuild, > or rebuild. Default would be rebuild. Then the logic is simple for each > data type.
That seems like a good idea, I don't see how the current infrastructure could provide enough information to skip this here. Add in there whether a reindex is needed, too, in the accepted return values (maybe a mask is needed, such as NOREWRITE|REINDEX). > Note that this doesn't deal with the special case of VARCHAR-->TEXT, but > just with changing typemods. Are there other cases of data *type* > conversions where no check or rebuild is required? Otherwise we might just > special case VARCHAR-->TEXT. It seems there's some new stuff for this in 8.4, around the notions of binary coercibility and type categories, which allow user defined types to be declared IO compatible with built-in types, e.g. citext/text. Maybe the case is not so special anymore? http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=22ff6d46991447bffaff343f4e333dcee188094d http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=4a3be7e52d7e87d2c05ecc59bc4e7d20f0bc9b17 > Oh, here's a general case: changing DOMAINs on the same base type should > only be a check, and changing from a DOMAIN to its own base type should be a > none. DOMAINs and CASTs are still on the todo list IIRC, so I'm not sure the current infrastructure around DOMAINs would be flexible (or complete) enough for the system to determine when the domain A to domain B type change is binary coercible. It has no CAST information to begin with, I guess. As far as reindexing is concerned, talking with RhodiumToad (Andrew Gierth) on IRC gave insights, as usual. Standard PostgreSQL supports two data type change without reindex needs: varchar to text and cidr to inet. In both cases, the types share the indexing infrastructure: same PROCEDUREs are in use in the OPERATORs that the index is using. Could it be that we already have the information we need in order to dynamically decide whether a heap rewrite and a reindex are necessary, even in case of user defined type conversions? Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers