Proposal - asynchronous functions

Asynchronous functions

*Problem*
Postgresql does not have support for asynchronous function calls.

*Solution*
An asynchronous function would allow a user to call a function and have
it return immediately, while an internal session manages the actual
processing. Any return value(s) of the function would be discarded.

*Value Added*
There are two types of primary usage for an asynchronous function:

* Building summary tables or materialized views.

* Running business logic functionality through untrusted languages

These function can be either run stand-alone or called by a trigger. The
proposed rules of an asynchronous function are:

* the result should not impact the statement run, meaning if there
is an error it should not cancel the transaction

* the user should not have to wait until the function is finished to
get control of the session back

* the long-running function should not be dependent on the user
keeping the session alive

*Current workaround*

Currently, the way to implement these types of functions are:

* Using the Listen/Notify calls.

* Adding a row to a queuing table and processing it as a cron job.

The problem with these workarounds are:

* In principal, going from the database outside, just to go back in
so that you have an external session controller, is awkward.
Listen/Notify is a great method to run a server function that is
not related to the database.

* Sometimes the connection in your daemon stops (from experience),
and there is no notification

* Some functions should be run immediately and not queued.

* They add complexity to the end user

*Proposal*

Add an Async command for functions ( ASYNC my_func(var1,var2) ) and add
an async optional keyword in trigger statements ( CREATE TRIGGER ...
EXECUTE ASYNC trig_func() ). This should cause an internal session to be
started that the function or trigger function will run in, disconnected
from the session it started in.

Sim Zacks