Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
PL/sh is OK, but both PL/Ruby and PL/Java play around with Warn_restart.
Are they using it to fake try/catch behavior? If so, see later thread
about moving to a simple set of try/catch macros.
I currently have this up and seemi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> PL/sh is OK, but both PL/Ruby and PL/Java play around with Warn_restart.
Are they using it to fake try/catch behavior? If so, see later thread
about moving to a simple set of try/catch macros.
I currently have this up and seemingly working for the
Am Sonntag, 25. Juli 2004 01:48 schrieb Tom Lane:
> One issue is that it may break existing PLs that override Warn_restart,
> since the semantics of doing that will have changed a bit. We can
> easily fix the PLs that are in our own CVS, but what are the
> implications for other PLs such as PL/R a
> I was just looking around the net to see exactly what Oracle's PL/SQL
> syntax is. It doesn't seem too unreasonable syntax-wise:
>
> BEGIN
> ... controlled statements ...
> EXCEPTION
> WHEN exception_name THEN
> ... error handling s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
| Gaetano Mendola <[EMAIL PROTECTED]> writes:
|
|>Tom Lane wrote:
|>| I was just looking around the net to see exactly what Oracle's PL/SQL
|>| syntax is. It doesn't seem too unreasonable syntax-wise:
|>| [ snip pl/sql syntax ]
|
|
|>
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
> | I was just looking around the net to see exactly what Oracle's PL/SQL
> | syntax is. It doesn't seem too unreasonable syntax-wise:
> | [ snip pl/sql syntax ]
> Is this sintax SQL standard driven ?
No, AFAIK it's just Oracle's sy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
| Bruce Momjian <[EMAIL PROTECTED]> writes:
|
|>So it allows functions to use subtransactions and recover from errors.
|>I thought that was more than we could do for 7.5 and in fact the release
|>notes now saw that will be done in a futu
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am _still_ unclear on what still needs to be done to complete NT and
> > PITR. Are you more aware of the open issues?
>
> NT: feature-wise, we need to commit the SAVEPOINT-syntax patch, which
> I think needs only minor adjustments,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am _still_ unclear on what still needs to be done to complete NT and
> PITR. Are you more aware of the open issues?
NT: feature-wise, we need to commit the SAVEPOINT-syntax patch, which
I think needs only minor adjustments, and we need to do something
I agree we don't want to add a savepoint on top of the exceptions as you
stated below.
I am _still_ unclear on what still needs to be done to complete NT and
PITR. Are you more aware of the open issues?
---
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> So it allows functions to use subtransactions and recover from errors.
> I thought that was more than we could do for 7.5 and in fact the release
> notes now saw that will be done in a future release.
I think there's only a day or two's work between her
Tom Lane wrote:
One issue is that it may break existing PLs that override Warn_restart,
since the semantics of doing that will have changed a bit. We can
easily fix the PLs that are in our own CVS, but what are the
implications for other PLs such as PL/R and PL/SH? Joe, Peter, any
comments?
I am
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yes. This is an integral part of finishing nested transactions.
> Oh, is this exceptions in functions or the ability to allow functions to
> keep executing after an SQL error?
Those are the same thing, aren't they? But yes, that's t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Are you suggesting these changes for 7.5?
>
> Yes. This is an integral part of finishing nested transactions.
Oh, is this exceptions in functions or the ability to allow functions to
keep executing after an SQL error?
--
Bruce M
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Yes. This is an integral part of finishing nested transactions.
>
> > Oh, is this exceptions in functions or the ability to allow functions to
> > keep executing after an SQL error?
>
> Those are the same thing,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are you suggesting these changes for 7.5?
Yes. This is an integral part of finishing nested transactions.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscri
Are you suggesting these changes for 7.5?
---
Tom Lane wrote:
> Currently, the way that ereport/elog processing works is:
>
> 1. Collect up all the error parameter information into an ErrorData
> structure. (This is somewh
Currently, the way that ereport/elog processing works is:
1. Collect up all the error parameter information into an ErrorData
structure. (This is somewhat nontrivial in itself, at least in the
ereport case, but I'll gloss over that here.)
2. Construct a log message and/or a client Error or Notic
18 matches
Mail list logo
