On Thu, 2 Jun 2005, Tom Lane wrote:
> Pavel Stehule <[EMAIL PROTECTED]> writes:
> > I din't find easy way how append variable only when block contains
> > EXCEPTION part. I wilcome any advice
>
> I was envisioning an action in the beginning of the EXCEPTION clause,
> viz
>
> exception_sect :
>
On Thu, 2 Jun 2005, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I should have commented on this earlier: I don't think exact Oracle
> > compatibility is _at all_ important.
>
> The results of Pavel's experiments prove that Oracle's behavior is
> pretty random --- it looks to me
On Fri, 3 Jun 2005, Neil Conway wrote:
> Pavel Stehule wrote:
> > So we can have only one procedure level scope variable, which is
> > initialized on start of exception and zeroized on the end of exception
> > block. This behavior is different from my patch, but is better for Oracle
> > compati
Pavel Stehule <[EMAIL PROTECTED]> writes:
> On Thu, 2 Jun 2005, Tom Lane wrote:
>> The results of Pavel's experiments prove that Oracle's behavior is
>> pretty random --- it looks to me like the chance results of whatever
> What I can speek. Oracle has session variable for saving err code of last
Pavel Stehule <[EMAIL PROTECTED]> writes:
> I din't find easy way how append variable only when block contains
> EXCEPTION part. I wilcome any advice
I was envisioning an action in the beginning of the EXCEPTION clause,
viz
exception_sect :
{ $$ = NIL; }
| K_
Neil Conway <[EMAIL PROTECTED]> writes:
> I should have commented on this earlier: I don't think exact Oracle
> compatibility is _at all_ important.
The results of Pavel's experiments prove that Oracle's behavior is
pretty random --- it looks to me like the chance results of whatever
quick-and-di
Pavel Stehule wrote:
So we can have only one procedure level scope variable, which is
initialized on start of exception and zeroized on the end of exception
block. This behavior is different from my patch, but is better for Oracle
compatibility and I prefere its.
I should have commented on th
> BEGIN
> -- do something perilous
> EXCEPTION
> WHEN OTHERS THEN -- nothing much
> END;
> IF SQLSTATE = '42000' THEN ...
I understand. My idea was detect local exception for local block, I can't
to see exception's information outside block and
>
> That might be taking the notion of bug-compatibility with PL/SQL
> a bit too far. For that matter, did you check whether Oracle
> actually treats it as a procedure-scope variable? Try having the
> exception block call another function and trap an error inside that.
> Does SQLCODE change in t
On Thu, 26 May 2005, Neil Conway wrote:
> Tom Lane wrote:
> > Alternatively we could make them local to any block that contains an
> > EXCEPTION clause, which would fix point 3 and also go a long way towards
> > addressing the unnecessary-overhead gripe. However that would mean that
> > an attemp
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Does Oracle support GET DIAGNOSTICS? If so, couldn't we just use
> > that? I can't see what good will become of making any slightly
> > useful information become available as magic variables of some
> > kind.
>
> Oracle actually de
Pavel Stehule <[EMAIL PROTECTED]> writes:
> What it is mean?
I think it means Oracle is broken ;-)
> So we can have only one procedure level scope variable, which is
> initialized on start of exception and zeroized on the end of exception
> block. This behavior is different from my patch, but i
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Does Oracle support GET DIAGNOSTICS? If so, couldn't we just use that?
> I can't see what good will become of making any slightly useful
> information become available as magic variables of some kind.
Oracle actually defines these things as parame
Tom Lane wrote:
> I suggest that what we should do is define SQLSTATE and SQLERRM
> similarly to FOUND: they are procedure-local variables that are
> assigned to by an occurrence of an error. I'd be inclined to make
> them start out NULL, too, not 0/"Successful completion".
Does Oracle suppor
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Alternatively we could make them local to any block that contains an
>> EXCEPTION clause, which would fix point 3 and also go a long way towards
>> addressing the unnecessary-overhead gripe. However that would mean that
>> an attempt to
Tom Lane wrote:
Alternatively we could make them local to any block that contains an
EXCEPTION clause, which would fix point 3 and also go a long way towards
addressing the unnecessary-overhead gripe. However that would mean that
an attempt to reference them from outside an exception handler wou
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Add PL/pgSQL SQLSTATE and SQLERRM support which sets these values on
> error.
I had not taken the time to review this patch before, but now that I
have looked at it I'm pretty unhappy with it. It creates new local
variables SQLSTATE and SQLERRM in *ever
Log Message:
---
Add PL/pgSQL SQLSTATE and SQLERRM support which sets these values on
error.
Pavel Stehule
Modified Files:
--
pgsql/doc/src/sgml:
plpgsql.sgml (r1.67 -> r1.68)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/plpgsql.sgml.diff
18 matches
Mail list logo
