RE: postgres crash on CURSORS

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> >> The check for abort state has to happen in the appropriate paths of
> >> execution, not in the parser.  Not all statements should reject on
> >> abort state.
> 
> > Are there any statements which should be executable on abort state
> > except ROLLBACK/COMMIT ?
> 
> I dunno ... but offhand, I see no really good reason for checking this
> in the parser rather than the way it's done now.  Presumably only
> utility statements would be candidates for exemption from abort checks,
> so checking in the switch statement in ProcessUtility makes sense to
> me --- that way the knowledge of the semantics of a given utility
> statement is localized.
>

Current abort check seems too late.
For example,is the following behavior preferable ?

=# begin;
BEGIN
=# aaa;
ERROR:  parser: parse error at or near "aaa"
=# select * from aaaa;
ERROR:  Relation 'aaaa' does not exist?? existence check ?? Why ??

reindex=# select * from t; -- t is a existent table
NOTICE:  (transaction aborted): queries ignored until END
*ABORT STATE*

> > The following is a sample patch for parser.c.
> 
> The specific patch you propose is definitely inferior to the currently-
> committed code, because it does not deal properly with COMMIT/ROLLBACK
> appearing within a list of queries.  If we are in abort state and
> the submitted query string is
> 
>     SELECT foo ; ROLLBACK ; SELECT bar
> 
> it seems to me that the correct response is to reject the first select
> and process the second.  The currently committed code does so, but
> your patch would fail.
>

It seems pg_parse_and_plan() returns NIL plan_list and NIL
querytree_list in this case.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp