I've been working through the expanded object code to try and get a demonstration of it working with PostGIS (still having some problems, but it's a learning experience). On an unrelated from, I noticed in the array expanded code, that the array code is managing its own copy of a cache of the flat representation and flat size,
https://github.com/postgres/postgres/blob/cf7dfbf2d6c5892747cd6fca399350d86c16f00f/src/backend/utils/adt/array_expanded.c#L247-L253 This seems like generic code, which any implementor is going to end up copying (after seeing it, and seeing how often the flatten size callback is being hit while debugging code, it seems like an obvious next thing to add to my expanded representation, once I get things working). Why isn't caching the flat representation and size (and short circuiting when the cache is already filled) part of the generic functionality PgSQL provides? Should it be? I guess it would imply a required function to dirty the EOH cache when changes are made to the in-memory data, but that seems no worse as part of the generic API than in all the client code. P. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
