How did I decide to remove functional interface and instead go with
SFRM_Materialize? Well, I benchmarked both implementations:

Benchmark: timing 1000 iterations of 0_old, 1_new, 2_old, 3_new, 4_old, 5_new...
     0_old: 11 wallclock secs ( 2.83 usr +  0.05 sys =  2.88 CPU) @ 347.22/s (n=1000)
     1_new:  9 wallclock secs ( 1.91 usr +  0.05 sys =  1.96 CPU) @ 510.20/s (n=1000)
     2_old: 10 wallclock secs ( 2.61 usr +  0.05 sys =  2.66 CPU) @ 375.94/s (n=1000)
     3_new: 10 wallclock secs ( 1.93 usr +  0.04 sys =  1.97 CPU) @ 507.61/s (n=1000)
     4_old: 13 wallclock secs ( 2.66 usr +  0.05 sys =  2.71 CPU) @ 369.00/s (n=1000)
     5_new: 12 wallclock secs ( 1.96 usr +  0.03 sys =  1.99 CPU) @ 502.51/s (n=1000)


If you want to re-create this benchmark on your configuration, checkout
revision between 19 and 24 because revision 25 obsoleted (and removed) old
version of function.

Have also in mind, that old API always fetched 6 attributes (4 found output
and 2 for debug) while new API fetched just one for this benchmark.

Each attribute fetch decrease performance for about 20 transactions in
second, so specifying many unneeded attributes isn't free. That's why new API
has attribute specification - both for performance and usability.

And at end, a well-known secret: since we are using materialized views
(which take place in PostgreSQL sort memory), increasing sort_mem parameter in
postgresql.conf will dramatically increase performance.