Re: Syntax decisions for pl/pgsql RAISE extension

2008/5/12 Tom Lane <tgl@[EMAIL PROTECTED]
>:
> "Kevin Grittner" <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
>
>         <signal statement> ::=
>              SIGNAL <signal value>
>                [ <set signal information> ]
>
>         <signal value> ::=
>                <condition name>
>              | <sqlstate value>
>
>         <condition name> ::=
>              <identifier>
>
>         <sqlstate value> ::=
>              SQLSTATE [ VALUE ] <character string literal>
>
>         <set signal information> ::=
>              SET <signal information item list>
>
>         <signal information item list> ::=
>              <signal information item> [ { <comma> <signal information
item> }... ]
>
>         <signal information item> ::=
>              <condition information item name> <equals operator> <simple
value specification>
>
> If we're willing to invent Postgres-specific <condition information item
> names> for MESSAGE, DETAIL, etc, then this is just about isomorphic to
> the proposed RAISE syntax, except that if you want an elog level other
> than ERROR you'd have to specify it as an item in the SET-list.
>
> BTW, the spec also uses <condition name> and <sqlstate value> as above
> in handler declarations, so it looks like both Pavel and I got it wrong
> about how to extend the EXCEPTION syntax: it should be
>         SQLSTATE [VALUE] 'xxxxx'
>

next step can be extension of GET DIAGNOSTIC statement ...

Pavel

p.s. CASE statement going from SQL/PSM too. so why not?

>                        regards, tom lane
>

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers