Re: Grammar-problems with pl/pgsql in gram.y

Klaus Reger wrote:
> Am Mittwoch, 16. Mai 2001 21:29 schrieb Jan Wieck:
> > For the EXCEPTIONS thing, well that's another issue. We could
> > of course simulate/generate some of the exceptions like "no
> > data found" and the other one I forgot (telling that a SELECT
> > INTO returned multiple results). But we cannot catch a
> > duplicate key error, a division by zero or a referential
> > integrity violation, because when it happens a statement is
> > half way done and the only way to cleanup is rolling back the
> > entire transaction (for now, Vadim is working on savepoints).
> > So I suggest you don't spend much of your time before we have
> > them.
> OK, I understand. For the beginning I only would like to have a possibility,
> to catch any exception and create my own error handling, ignoring any
> transaction-stuff. Because I have to port Procedures from Oracle to
> PostgreSQL, I am looking, to imitate the way Oracle takes.
>
> As I understand with my actual knowledge, this would mean, that every(!) call
> of elog, which terminates the process, has to be caught. But this seems to
> great for a new Postgres-hacker, like I am. Or do you see any other
> possibility (maybe extending PLpgSQL_execstate)?

Every(!) call to elog with ERROR (or more severe) level
causes finally a longjump() back into the tcop mainloop.
PL/pgSQL and PL/Tcl do catch it - PL/pgSQL to tell something
on DEBUG level and PL/Tcl mainly to unwind the Tcl
interpreters call stack. But the backend is in an
inconsistent state at that time, and any subsequent call to
access methods could cause unpredictable results up to
complete database corruption. There is no other way right now
than to go ahead and continue with transaction abort.

Imitation of the Oracle way is something many ppl around here
would appreciate, but not at the risk of corrupting the
entire database - that's too high a price.

That said, you'll have little to no chance of getting this
feature applied to the CVS. Doing EXCEPTIONS requires
savepoints and a real "back to statements start state"
functionality. The recent approach of "simulating CURSOR"
just on the PL grammar level without real cursor support in
the SPI layer failed for exactly the same reason. Before we
know "how" to do it, we cannot decide on the exact
appearence, because implementation details might "require" at
least some difference to other databases. If we accept such a
"fake" only approach, we introduce backward compatibility
problems, since somebody will tell us for sure "I used the
syntax of 7.2 already and porting my +20K line application
now ...". In PostgreSQL it's easier to get new *features*
added than existing features ripped out - and people rely on
that.

Jan

PS:
Aber laß mal den Kopf nicht hängen, wir finden bestimmt was
wo Du Dich austoben kannst :-)

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com