Re: [PATCHES] plpgsql raise - parameters can be expressions

2005-06-15 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes: BTW, is there any value in a separate EXCEPTION type? ISTM that an exception is just a SQLSTATE, which is in turn just a string. A separate exception type does simplify the parsing of RAISE, but I wonder if it would be useful to be able to also allow

Re: [PATCHES] plpgsql raise - parameters can be expressions

2005-06-13 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: Next problem, visibility custom exceptions. When I define exception variable I can't rethrown exceptions outside block when is defined. What is outside - some custom exception? I don't think this is an issue. A custom exception is really just a name

Re: [PATCHES] plpgsql raise - parameters can be expressions

2005-06-13 Thread Pavel Stehule
I would also expect that matching is by SQLSTATE, that is if I write DECLARE foo EXCEPTION = '12345'; ... RAISE ERROR foo, ...; then some outer block written as DECLARE bar EXCEPTION = '12345'; ... EXCEPTION WHEN bar THEN ... if we accept

Re: [PATCHES] plpgsql raise - parameters can be expressions

2005-06-13 Thread Neil Conway
Tom Lane wrote: That doesn't bother me either, seeing that an undefined variable isn't detected at compile time anywhere else. However, fixing the SQLSTATE tests by removing them doesn't seem like a great solution ... Yeah, true, I can just invoke the function to trigger the undefined

Re: [PATCHES] plpgsql raise - parameters can be expressions

2005-06-13 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes: Tom Lane wrote: Actually, the reason I didn't do something about RAISE in 8.0 was that I thought we should reconsider the whole design of the statement The ensuing discussion on this sounds good to me; should I apply Pavel's RAISE patch now, or wait for

Re: [PATCHES] plpgsql raise - parameters can be expressions

2005-06-13 Thread Neil Conway
Tom Lane wrote: But you had mentioned wanting to look at reducing overhead by using exec_eval_expr(); were you intending to do that before committing? I'm a bit busy with other matters at the moment, so I'll probably look at it later. One question is whether we should make use of

[PATCHES] plpgsql raise - parameters can be expressions

2005-06-12 Thread Pavel Stehule
Hello, I did trivial patch which eliminate limit raise command. Using expressions instead of variables are a little bit expensive, but little. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with

Re: [PATCHES] plpgsql raise - parameters can be expressions

2005-06-12 Thread Pavel Stehule
On Mon, 13 Jun 2005, Michael Glaesemann wrote: On Jun 13, 2005, at 2:07 PM, Pavel Stehule wrote: I did trivial patch which eliminate limit raise command. Using expressions instead of variables are a little bit expensive, but little. I'm right in thinking this essentially does