> -----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 ?
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
> > 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.
In response to
pgsql-hackers by date
|Next:||From: Karel Zak||Date: 2000-04-05 11:33:56|
|Subject: Re: caching query results|
|Previous:||From: Tom Lane||Date: 2000-04-05 06:10:52|
|Subject: Re: postgres crash on CURSORS |