RE: postgres crash on CURSORS

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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(at)tpf(dot)co(dot)jp