Re: help with bison

On Thu, 11 Apr 2002, Tom Lane wrote:

> Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> > PrepareStmt: PREPARE name AS prepare_query types_prepare_clause
> > prepare_store
>
> > There is a reasonably clear problem here. prepare_query encompasses much
> > of the grammar of the parser so it will definately cause shift/reduce and
> > reduce/reduce conflicts with the other two productions which follow
> > it. Easy solution?
>
> > PrepareStmt: PREPARE name types_prepare_clause prepare_store AS
> > prepare_query
>
> Is there any existing standard to follow for the syntax of these
> commands?

SQL92 lists:

<prepare statement> ::=
PREPARE <SQL statement name> FROM <SQL statement variable>

Where <SQL statement variable> can resolve to:

<preparable statement> ::=
<preparable SQL data statement>
| <preparable SQL schema statement>
| <preparable SQL transaction statement>
| <preparable SQL session statement>
| <preparable implementation-defined statement>

<preparable SQL data statement> ::=
<delete statement: searched>
| <dynamic single row select statement>
| <insert statement>
| <dynamic select statement>
| <update statement: searched>
| <preparable dynamic delete statement: positioned>
| <preparable dynamic update statement: positioned>

<preparable SQL schema statement> ::=
<SQL schema statement>

<preparable SQL transaction statement> ::=
<SQL transaction statement>

<preparable SQL session statement> ::=
<SQL session statement>

<dynamic select statement> ::= <cursor specification>

<dynamic single row select statement> ::= <query specification>

So, the form is (according to the yacc code):

PREPARE name FROM prepare_query

This seems a lot simpler. What is 'types_prepare_clause' used for? I
presume storage relates to whether or not all backends can see the
prepared statement? (As a note to those interested in statement
preparation, this is not the same as variable binding and so requires no
modification of the FE/BE protocol).

As a side note, I'm not sure I really see the point of preparable SQL. The
only real use I can think of is if the query could be prepared on the
client side. This would require modification of the parser (a few
#ifdefs), a few client side functions, some memory storage and a
modification of the FE/BE protocol to be able to accept parsed query
nodes. This would allow the backend to spend as little time in the parser
as possible, if that is desirable. It removes the ability to share
prepared queries between backends however.

Gavin