Skip site navigation (1) Skip section navigation (2)

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
Message-ID: (view raw, whole thread or download thread mbox)
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.

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group