Re: Parser extensions (maybe for 10?)

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: 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 05:28:20
Message-ID: CAKFQuwaZFq4XgdZOadbMOwEw9-QUYcUJ_xAVV3eJf_pOY6kRnA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 11, 2016 at 9:58 PM, Tsunakawa, Takayuki <
tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:

> *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.
>

​As recently discovered there is more than one reason why an intelligent
driver, like the JDBC standard at least requires in a few instances,
requires knowledge of at least some basic structure​

​of the statements it sees before sending them off to the server.
Furthermore, and particularly in the JDBC example you provide, my first
reaction is that it would be a massive encapsulation violation to try and
get PostgreSQL to understand "{? = call funcname(args)}" and similar higher
level API specifications.

I think PostgreSQL can do quite well by saying, hey this is what we are and
this is what we do. Compatibility has merit but I'm sure at least some of
those items can make it into the bison files - regardless of whether those
changes end up being accepted into core. Small-scale forking like this
seems like it would be easier to accomplish if not preferable to making the
entire thing modular. We have that option to offer others since we are an
open source project.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2016-04-12 05:42:10 Re: Parser extensions (maybe for 10?)
Previous Message Craig Ringer 2016-04-12 05:22:11 Re: Parser extensions (maybe for 10?)