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