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 and
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
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
-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 ]
|
|
|Is
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
-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 future
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 syntax.
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
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 somewhat
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 unsubscribe
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, aren't they?
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 Momjian
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 the
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
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 here
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
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
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, and we
18 matches
Mail list logo
