Re: Syntax decisions for pl/pgsql RAISE extension
От | Tom Lane |
---|---|
Тема | Re: Syntax decisions for pl/pgsql RAISE extension |
Дата | |
Msg-id | 23943.1210617839@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Syntax decisions for pl/pgsql RAISE extension ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Syntax decisions for pl/pgsql RAISE extension
Re: Syntax decisions for pl/pgsql RAISE extension |
Список | pgsql-hackers |
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> 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
В списке pgsql-hackers по дате отправления: