Re: Parser extensions (maybe for 10?) - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject Re: Parser extensions (maybe for 10?)
Date
Msg-id 0A3221C70F24FB45833433255569204D1F54C336@G01JPEXMBYT05
Whole thread Raw
In response to Parser extensions (maybe for 10?)  (Arcadiy Ivanov <arcadiy@gmail.com>)
Responses Re: Parser extensions (maybe for 10?)
List pgsql-hackers

From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Arcadiy Ivanov

Currently the parser and lexer are fully fixed at compile-time and not amenable to the extensions - extensions are only capable of introducing functions etc.

There is, however, an advantage to being able if not add or alter complete statements (which would be nice), but to at least augment portions of syntax for existing ones in some places.

 

I saw the following discussion in the past, but I haven’t read it:

 

Pluggable Parser

http://www.postgresql.org/message-id/BF2827DCCE55594C8D7A8F7FFD3AB77159878C2A@szxeml521-mbs.china.huawei.com

 

I’m interested in the pluggable, extensible parser for two purposes.  One is to add compatibility for other databases.

 

The other is for the ODBC (and possibly JDBC) driver.

The ODBC/JDBC specs require some unique syntax constructs, e.g. {? = call funcname(arguments)} to call stored procs/functions.  Currently, the ODBC/JDBC drivers are forced to parse and convert SQL statements.  It is ideal for PostgreSQL itself to understand the ODBC/JDBC syntax, and eliminate the burdon of parsing statements from the JDBC/ODBC drivers.

 

Regards

Takayuki Tsunakawa

 

 

 

 

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Parser extensions (maybe for 10?)
Next
From: Andres Freund
Date:
Subject: Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.