Jim Nasby <jim.na...@bluetreble.com> writes: > Without having read the patch, I think this is great. I've been wishing > for something like this while working on my variant data type.
> Are there any cases where we would want to use this on a non-variant? > Perhaps types where we're paying an alignment penalty? What do you mean by non-variant? The use cases that have come to mind for me are: * arrays, of course * composite types (records) * PostGIS geometry type * JSONB, hstore * possibly regex patterns (we could invent a data type representing these and then store the compiled form as a deserialized representation; although there would be some issues to be worked out to get any actual win, probably) The principal thing that's a bit hard to figure out is when it's a win to convert to a deserialized representation and when you should just leave well enough alone. I'm planning to investigate that further in the context of plpgsql array variables, but I'm not sure how well those answers will carry over to datatypes that plpgsql has no intrinsic understanding of. 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