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 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'
>
> regards, tom lane
>
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.
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
