Andrew Dunstan wrote:

> It could be done by putting the SPL parser in front of the SQL parser.
> Maybe Luss will tell us how it was done ;-)

We added SPL 'CREATE [OR REPLACE] PROCEDURE' and 'CREATE [OR REPLACE]
FUNCTION' Syntax support to the main scanner, parser for the backend.
By entering exclusive state for scanning the body, similar to quoted
string handling for the PostgreSQL language-agnostic function creation
syntax, we achieve the desired result. We return the scanner to
INITIAL state by encountering the last END token; based upon the block
depth level, that we are keeping track of in the exclusive state.

The rest of the handling, behind the parser, conforms to standard
PostgreSQL Language-agnostic Function creation with all the required
attributes set for
PG_PROC via the CreateFunctionStmt node.

Please note that I am using 'PG_PROC' and 'CreateFunctionStmt' just to
maintain the standard PostgreSQL Reference Point, our implementation
actually differs
in terms of catalog(s), structure(s) naming as we went for
semi-bifurcation between procedures and functions to meet our future
needs. During the process, however, we have ensured full backward
compatibility.

This list of required attributes includes the language to be set as
EDB-SPL (configured as the default PL for EnterpriseDB), in addition
to other attributes
such as parameter(s) information etc.

Subsequently, like for any other PL in PostgreSQL, SPL Language
Handler maintains the responsibility of performing the compilation and
execution of the SPL
proc/function body source text.

-Affan
Lead Database Architect,
EnterpriseDB Corporation.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match