Re: help with bison
От | Gavin Sherry |
---|---|
Тема | Re: help with bison |
Дата | |
Msg-id | Pine.LNX.4.21.0204120150490.18266-100000@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: help with bison (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, 11 Apr 2002, Tom Lane wrote: > Gavin Sherry <swm@linuxworld.com.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 rowselect statement> | <insert statement> | <dynamic select statement> | <update statement:searched> | <preparable dynamic delete statement: positioned> | <preparable dynamic updatestatement: 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
В списке pgsql-hackers по дате отправления: