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

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,
andany 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
thesame reason.  Before  we   know   "how"  to  do  it,  we  cannot  decide  on  the  exact   appearence, because
implementationdetails 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
syntaxof 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@Yahoo.com #



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