On Thu, Dec 1, 2011 at 8:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > What I want to see is some mechanism that pushes this out to the > individual datatypes, so that both core and plug-in datatypes have > access to the benefits. There are a number of ways that could be > attacked, but the most obvious one is to invent additional, optional > support function(s) for btree opclasses.
I feel like what's missing here is a way for the catalogs to refer to a function that doesn't take FunctionCallInfo as an argument. But it strikes me that it wouldn't be very hard to design such a mechanism. It seems like all we really need to do is decide on a nomenclature. The simplest possible approach would probably be to just refer to functions by name. In other words, we add a text or name column to pg_amproc, and then inside the backend there's a function whose job it is to map the string to a function address. However, that would have the annoying effect of causing catalog bloat, so I'm inclined to instead propose an 8-byte integer. (A 4-byte integer is enough, but would increase the risk of collisions between values that might be chosen by third party extensions.) So, the API to this would look something like this: void register_arbitrary_function_pointer(int64 handle, void *funcptr); void *get_arbitrary_function_pointer(int64 handle); So the idea is that if you need to refer to an arbitrary function in a system catalog (such as pg_amproc), you generate a random non-zero 64-bit integer, stuff it into the catalog, and then register the same 64-bit integer with the appropriate function pointer. To avoid increasing backend startup time, we could have a Perl script generate a prefab hash table for the built-in functions; loadable modules would add their entries at PG_init() time using register_arbitrary_function_pointer. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers