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
