Tom Lane wrote:
Those cases are for places where the spec defines similar cases under
the error classes "SQL Routine Exception" and "External Routine Exception".
You can blame me for having assumed that plpgsql didn't need to
distinguish these cases.
Well, in and of itself, I agree it is probab
Neil Conway <[EMAIL PROTECTED]> writes:
> Pavel Stehule wrote:
>> can you show sample, please?
> modifying_sql_data_not_permitted, null_value_not_allowed,
> prohibited_sql_statement_attempted and reading_sql_data_not_permitted
> are the examples I can see from scanning plerrcodes.h. If we had th
Pavel Stehule wrote:
can you show sample, please?
modifying_sql_data_not_permitted, null_value_not_allowed,
prohibited_sql_statement_attempted and reading_sql_data_not_permitted
are the examples I can see from scanning plerrcodes.h. If we had this to
do over again, I'm not sure I see the poi
hello,
sorry, exception variables don't solve this problem too. But we can detect
it in compile-time. I don't wont to complicate raise syntax.
best regards
Pavel
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Tue, 26 Jul 2005, Neil Conway wrote:
> Neil Conway wrote:
> > Not at the moment. I believe we have agreed that it would be better to
> > remove the concept of "exception variables" and just use strings, but I
> > haven't implemented this yet.
>
> BTW, one minor annoyance I noticed: a builtin
Neil Conway wrote:
Not at the moment. I believe we have agreed that it would be better to
remove the concept of "exception variables" and just use strings, but I
haven't implemented this yet.
BTW, one minor annoyance I noticed: a builtin condition name can
actually map to multiple SQLSTATE va
Bruce Momjian wrote:
Where are we on this patch? Is there something to apply?
Not at the moment. I believe we have agreed that it would be better to
remove the concept of "exception variables" and just use strings, but I
haven't implemented this yet. I'm happy to do that, but I might not get
Where are we on this patch? Is there something to apply?
---
Pavel Stehule wrote:
> On Fri, 8 Jul 2005, Neil Conway wrote:
>
> > Pavel Stehule wrote:
> > > ok, but don't forget, please, on exception part.
> >
> > What do
Pavel Stehule wrote:
BEGIN
EXCEPTION WHEN * THEN
equvalent rules for raise have to be in *
is true?
I'm sorry, but I'm still not sure what you mean.
-Neil
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your
On Fri, 8 Jul 2005, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > BTW, do have we reached a consensus on this?
>
> Doesn't look that way --- I tend to agree with you that we could avoid
> inventing declared exceptions at all, but Pavel is definitely not happy
> with it, and AFAIR
On Fri, 8 Jul 2005, Neil Conway wrote:
> Pavel Stehule wrote:
> > ok, but don't forget, please, on exception part.
>
> What do you mean?
>
> -Neil
>
BEGIN
EXCEPTION WHEN * THEN
equvalent rules for raise have to be in *
is true?
Pavel
---(end of broadcast)--
Pavel Stehule wrote:
ok, but don't forget, please, on exception part.
What do you mean?
-Neil
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so th
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, do have we reached a consensus on this?
Doesn't look that way --- I tend to agree with you that we could avoid
inventing declared exceptions at all, but Pavel is definitely not happy
with it, and AFAIR no one else has weighed in. Maybe we need to tak
On Fri, 8 Jul 2005, Neil Conway wrote:
> Neil Conway wrote:
> > Ah, I see. I would be content to allow opt_sqlstate to be either a
> > string literal, a T_WORD (predefined error condition), or a TEXT
> > variable. If users need to throw a sqlstate that is derived from a SQL
> > expression, they
Neil Conway wrote:
Ah, I see. I would be content to allow opt_sqlstate to be either a
string literal, a T_WORD (predefined error condition), or a TEXT
variable. If users need to throw a sqlstate that is derived from a SQL
expression, they can always assign to a TEXT variable and then specify
t
Tom Lane wrote:
RAISE NOTICE '12' !! '345', ...
Is !! an infix operator (using both strings as arguments) or a postfix
operator (in which case '345' is the format)?
Ah, I see. I would be content to allow opt_sqlstate to be either a
string literal, a T_WORD (predefined error condition)
>
> I really don't like the idea of introducing a new concept into the
> language ("exception variables") to resolve some ambiguous syntax. It
> would be another matter if exception variables actually provided
> something that strings do not...
>
In this time e.variables does it - only holds
On Wed, 6 Jul 2005, Tom Lane wrote:
> Pavel Stehule <[EMAIL PROTECTED]> writes:
> > if I use registered sqlstate, plpgsql knows text message.
>
> No, it does not. I already pointed out that tying a single error
> message to a SQLSTATE is unreasonable, because that's not how the
> SQL committee i
Pavel Stehule <[EMAIL PROTECTED]> writes:
> if I use registered sqlstate, plpgsql knows text message.
No, it does not. I already pointed out that tying a single error
message to a SQLSTATE is unreasonable, because that's not how the
SQL committee intended SQLSTATEs to be used. I haven't looked a
>
> This would require promoting all the options for LEVEL into fully
> reserved words. You really can't get around the fact that you need
> something pretty identifiable to terminate the expression.
>
> It might work to require parentheses:
>
> RAISE LEVEL ( sqlstate expression ), 'fmt'
> and maybe the short-term cheesy thing to do is special-case exactly this
> syntax:
>
> RAISE LEVEL [ SQLSTATE(text_expr), ] text_expr [, ... ]
>
> which would give us the minimum functionality with a clear path to
> expansion later.
>
or only RAISE LEVEL SQLSTATE(text_expr)|text_expr [,
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think it is a bad idea, if not actually impossible, to have an
>> expression for sqlstate with no separating syntax before the 'fmt';
>> especially not if you'd like to also allow an expression for the 'fmt'.
> I don't actually see muc
> "exception variable" in the first place. What does it buy us over simply
> using a string? In other words, if we allowed the syntax:
>
> RAISE LEVEL [ opt_sqlstate ] 'fmt' [, expr ... ]
>
> where `opt_sqlstate' is either empty, a T_WORD we find in the table of
> predefined condition names, or
Tom Lane wrote:
I think it is a bad idea, if not actually impossible, to have an
expression for sqlstate with no separating syntax before the 'fmt';
especially not if you'd like to also allow an expression for the 'fmt'.
I don't actually see much of a need to allow 'fmt' to be an expression,
e
Neil Conway <[EMAIL PROTECTED]> writes:
> I wonder if there is any point introducing the concept of an
> "exception variable" in the first place. What does it buy us over simply
> using a string?
Not a lot really, except for keeping things similar to the Oracle way of
doing it ... but that's a n
Pavel Stehule wrote:
Per small recent discussion I corrected patch user's exception.
Attached is a revised patch. I haven't looked at the documentation
changes yet (more work is needed I believe) or some of the error message
text.
I was originally hoping to make "exception variables" a litt
On Mon, 4 Jul 2005, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Pavel Stehule wrote:
> >> Per small recent discussion I corrected patch user's exception.
>
> > I'll review and apply this in the next day or so.
>
> Have we got a consensus yet on the behavior? There seemed to be
Neil Conway <[EMAIL PROTECTED]> writes:
> Pavel Stehule wrote:
>> Per small recent discussion I corrected patch user's exception.
> I'll review and apply this in the next day or so.
Have we got a consensus yet on the behavior? There seemed to be no
meeting of the minds at all the last time I pai
Pavel Stehule wrote:
Per small recent discussion I corrected patch user's exception.
I'll review and apply this in the next day or so.
Next ToDo (needs discussion):
+ Optional message in raise stmt for user's or system exception
raise exception division_by_zero;
+ Possibility rethr
Hello
Per small recent discussion I corrected patch user's exception.
diff: User can choise any sqlstate (without class U0, which I reserve as
range for default values sqlstates - if user don't spec sqlstate, is
used value from this range). There is only basic changes in documentation
and need
30 matches
Mail list logo
