"Zeugswetter Andreas OSB sIT" <[EMAIL PROTECTED]> writes:
> Other db's go with SQLCODE and SQLSTATE.
> Would SQLCODE be better than ERRCODE ?
No, because SQLCODE has a specific meaning, and it's *not* either a
condition name or a SQLSTATE --- it's the old SQL89-era error code
numbering. I think
> So right now I'm thinking I like my original proposal
> http://archives.postgresql.org/pgsql-hackers/2008-05/msg00357.php
> with the exception that we should go with
> SQLSTATE 'xyzzy'
> as the syntax in EXCEPTION lists. Also I'm willing to go with
> ERRCODE rather than CODE as the name o
Decibel! <[EMAIL PROTECTED]> writes:
> Not to be a PITA about this, but I reeally think users are going to
> complain if we remove the % replacement stuff... Is there no way to
> keep that with the new syntax?
Uh, I didn't remove anything.
regards, tom lane
--
Sent v
On May 13, 2008, at 11:53 AM, Tom Lane wrote:
So right now I'm thinking I like my original proposal
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00357.php
with the exception that we should go with
SQLSTATE 'xyzzy'
as the syntax in EXCEPTION lists.
Not to be a PITA about this
2008/5/13 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> who write this patch?
>
> Well, like I said, I'm willing to adjust the patch to whatever syntax
> we come up with.
>
> After sleeping on it I'm a bit less excited about using the SQL/PSM
> SIGNAL syntax; the re
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> who write this patch?
Well, like I said, I'm willing to adjust the patch to whatever syntax
we come up with.
After sleeping on it I'm a bit less excited about using the SQL/PSM
SIGNAL syntax; the reason being that if we use that, and then sometime
in
On May 12, 2008, at 11:53 AM, Tom Lane wrote:
3. I think we should allow the user to specify the error message the
same way as the other options, that is
RAISE level USING MESSAGE = string_expression [ , ... ]
The %-format business has always struck me as a bit weird, and it's
much more s
2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I like this syntax, but I am not if it's good idea add new similar
>> statement. I don't know - but maybe it's can be better then extending
>> RAISE - and way to get consensus.
>
> I looked a bit more at the SQ
Robert Treat <[EMAIL PROTECTED]> writes:
> On Monday 12 May 2008 14:40:46 Pavel Stehule wrote:
>> In plpgsql I prefer PL/SQL syntax.
> I think nod's toward PL/SQL compatability should be given in general.
This position seems just about entirely unhelpful for resolving the
problem at hand, because
On Monday 12 May 2008 14:40:46 Pavel Stehule wrote:
> 2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> > "Pavel Stehule" <[EMAIL PROTECTED]> writes:
> >> 2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> >>> It would get less annoying if we allowed user-declared exception names.
> >>
> >> Tom, it's exactly like m
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I like this syntax, but I am not if it's good idea add new similar
> statement. I don't know - but maybe it's can be better then extending
> RAISE - and way to get consensus.
I looked a bit more at the SQL spec. It already defines a MESSAGE_TEXT, whi
2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> I'm probably in the minority, but I care more about SQL/PSM
>> compatibility than Oracle compatibility.
>
> Well, a different line of attack would be to leave RAISE as-is and adopt
> the SQL/PSM syntax for a m
2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> I'm probably in the minority, but I care more about SQL/PSM
>> compatibility than Oracle compatibility.
>
> Well, a different line of attack would be to leave RAISE as-is and adopt
> the SQL/PSM syntax for a m
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> I'm probably in the minority, but I care more about SQL/PSM
> compatibility than Oracle compatibility.
Well, a different line of attack would be to leave RAISE as-is and adopt
the SQL/PSM syntax for a modernized command. What I'm seeing in Part 4
is
2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
>>> It would get less annoying if we allowed user-declared exception names.
>
>> Tom, it's exactly like my patch that you rejected two years ago.
>
> Uh, no, not "exactly
2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> I've started to look over Pavel's revised RAISE patch
> http://archives.postgresql.org/pgsql-patches/2008-05/msg00187.php
> and I've got a few quibbles with the syntax choices.
>
> Pavel proposes extending RAISE like this:
>
> RAISE level 'format' [, expres
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
>> It would get less annoying if we allowed user-declared exception names.
> Tom, it's exactly like my patch that you rejected two years ago.
Uh, no, not "exactly like" --- that patch doesn't have anything to do
2008/5/12 Tom Lane <[EMAIL PROTECTED]>:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>> I agree that the % formatting in the RAISE message is weird, but it is
>> useful.
>
> Sure, I'm not proposing removing it.
>
>> What would we do if the user specifies a %-formatted message as well
>> as a MESSAG
2008/5/12 Kevin Grittner <[EMAIL PROTECTED]>:
Tom Lane <[EMAIL PROTECTED]> wrote:
>
>> Now, the elephant in the room is the issue of Oracle compatibility.
>> None of this looks anything even a little bit like Oracle's RAISE
>> command. Oracle allows
>> RAISE exception_name ;
>> RA
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I agree that the % formatting in the RAISE message is weird, but it is
> useful.
Sure, I'm not proposing removing it.
> What would we do if the user specifies a %-formatted message as well
> as a MESSAGE option?
Throw an error (just like if they speci
On Tue, May 13, 2008 at 2:53 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> 1. The parentheses around the USING list seem useless; let's drop 'em.
Yes.
>
> 2. I think the separation between SQLSTATE and CONDITION is just
> complication. A SQLSTATE is required to be exactly 5 digits and/or
> upper
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> Now, the elephant in the room is the issue of Oracle compatibility.
> None of this looks anything even a little bit like Oracle's RAISE
> command. Oracle allows
> RAISE exception_name ;
> RAISE ;
I'm probably in the minority, but I care mo
I've started to look over Pavel's revised RAISE patch
http://archives.postgresql.org/pgsql-patches/2008-05/msg00187.php
and I've got a few quibbles with the syntax choices.
Pavel proposes extending RAISE like this:
RAISE level 'format' [, expression [, ...] ] [ USING ( option = value [, ... ]
)
23 matches
Mail list logo