Re: Implementing SQL/PSM for PG 8.2

From: Affan Bin Salman <affans(at)gmail(dot)com>
To: andrew(at)dunslane(dot)net
Cc: luss(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Implementing SQL/PSM for PG 8.2
Date: 2005-06-29 16:21:20
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 ;-)

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

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.

Lead Database Architect,
EnterpriseDB Corporation.

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2005-06-29 16:31:03 Change Ownership Permission Checks
Previous Message Pavel Stehule 2005-06-29 15:59:26 Proposal: associative arrays for plpgsql (concept)