Re: Time to drop old-style (V0) functions?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Time to drop old-style (V0) functions?
Date: 2016-12-09 12:52:50
Message-ID: CA+TgmobZ953ejCC-6E1d+KcRabU0hVMK5UWybZ7P9p1xop-v-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 8, 2016 at 5:53 PM, Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2016-12-09 12:54:18 Re: pg_background contrib module proposal
Previous Message Andrew Borodin 2016-12-09 12:48:18 Re: pg_background contrib module proposal