On Thu, Dec 8, 2016 at 5:53 PM, Andres Freund <and...@anarazel.de> wrote: > I mean throwing an error. Silently assuming V1 seems like a horrible > idea to me. It doesn't seem unlikely that we want to introduce a new > call interface at some point given the runtime cost of the current one, > and that'd just bring back the current problem.
I don't have a problem with getting rid of V0; I think it's an annoyance. But I think a much more interesting question is how to redesign this interface. I think V0 actually had the right idea in passing arguments as C arguments rather than marshaling them in some other data structure. If the function doesn't need flinfo or context or collation and takes a fixed number of argument each of which is either strict or a pass-by-reference data type (where you can use DatumGetPointer(NULL) to represent a NULL!) and either never returns NULL or returns a pass-by-reference data type, then you don't need any of this complicated fcinfo stuff. You can just pass the arguments and get back the result. That's less work for both the caller (who doesn't have to stick the arguments into an fcinfo) and the callee (who doesn't have to fish them back out). In the sortsupport machinery, we've gone to some lengths to make it possible - at least in the context of sorts - to get back to something closer to that kind of interface. But that interface goes to considerable trouble to achieve that result, making it practical only for bulk operations. It's kind of ironic, at least IMHO, that the DirectionFunctionCall macros are anything but direct. Each one is a non-inlined function call that does a minimum of 8 variable assignments before actually calling the function. There obviously has to be some provision for functions that actually need all the stuff we pass in the V1 calling convention, but there are a huge number of functions that don't need any of it. -- 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