Re: Parser extensions (maybe for 10?)

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: Arcadiy Ivanov <arcadiy(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parser extensions (maybe for 10?)
Date: 2016-04-12 04:58:05
Message-ID: 0A3221C70F24FB45833433255569204D1F54C336@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-owner(at)postgresql(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-04-12 05:00:38 Re: [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.
Previous Message Craig Ringer 2016-04-12 04:45:33 Re: Parser extensions (maybe for 10?)