On 3/10/15 5:25 PM, Tom Lane wrote:
Jim Nasby <jim.na...@bluetreble.com> writes:
That said, this pattern with fn_extra is repeated a lot, even just in
the backend (not counting contrib or extensions). It would be nice if
there was generic support for this.
What do you mean by "generic support"? Most of those functions are doing
quite different things with fn_extra --- granted, nearly all of them are
caching something there, but I don't see very much that a "generic"
infrastructure could bring to the table.
At a glance, almost all the use under src/backend is doing some
combination of 3 things: get_typlenbyvalalign(), get_type_io_data() or
getting some operator for a type. This is most notable for records,
arrays and ranges (though, records actually need an array of this info,
so maybe we're out of luck there). That pattern exists outside of
backend too; I think it's used in contrib, and I know at least one
extension does this.
So my thought was something that accepted fcinfo, IOFuncSelector, and
TypeCacheEntry.flags. If IOFuncSelector was set, use get_type_io_data;
else use get_typlenbyvalalign. If TypeCacheEntry.flags is set also look
up the operator.
Hmm... now that I look at it, the only use of get_type_io_data in
src/backend seems to be to support arrays. Ranges make use of it too,
but there's a comment in there that it returns more than what's needed.
Even if a generic support function doesn't make sense, there's a lot of
repeated fn_extra code for arrays and records. It would be good to at
least refactor that like what was done for rangetypes. That process
might provide a more obvious answer to how this could be done generically.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
