plpgsql: RAISE
От | Richard Huxton |
---|---|
Тема | plpgsql: RAISE |
Дата | |
Msg-id | 000e01c111f0$4af6dc40$1001a8c0@archonet.com обсуждение исходный текст |
Ответы |
Re: plpgsql: RAISE |
Список | pgsql-hackers |
Muggins here volunteered to get RAISE to accept any expression that evaluates to a string rather than just a string constant. Think I can see why it wasn't that way already. Had a look, and this is easy enough: RAISE NOTICE ''Hello '' || $1 || '' World''; Also, I can do: RAISE NOTICE ''Hello '' || ''% World'',$1; But I don't think I can do both. Haven't looked at lex+9yacc since university days, but I think we've only got one token of look-ahead. This means we can't read the expression and *then* decide which option we are in. (For those who haven't looked at that bit of the code recently plpgsql_read_expression() slurps up to and including a closing token - either a ';' or ',' above. You've then lost that finishing token) The closest I can get is something like: RAISE NOTICE ''Hello '' || ''% World'',$1; -- Old style RAISE IN NOTICE ''Hello '' || $1 || '' World''; -- New "INline" style Obviously we can use a new token rather than "IN", but it'll do while I'm testing. AFAICT there are 4 options: 1. Break the old % format - it's redundant now anyway 2. Add a new token as above 3. Add another parameter to plpgsql_read_expression() so we can unget the closing token. 4. Alter plpgsql_read_expression() to accept more than one closing token, and it stops when it reads any of them. I'm averse to #1 (unless maybe it was accompanied with a small sed/perl script to automatically fix any code in a pg_dump file) I don't like gratuitously adding syntax noise with #2. I don't know whether #3 is even possible. Does anyone more familiar with yacc/bison know? The solution for #4 is going to add complexity to read_expression() - presumably not a speed problem (we're only parsing once) but it'd be nice to keep things as simple as possible. The only other things I need to look at are checking I've freed up any store that's been allocated and casting the expression to text where PG can't figure that out for itself. These are obviously just a matter of getting a little more familiar with the code. Any advice/suggestions gratefully received people. - Richard Huxton
В списке pgsql-hackers по дате отправления: