plpgsql: RAISE

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема plpgsql: RAISE
Дата
Msg-id 000e01c111f0$4af6dc40$1001a8c0@archonet.com
обсуждение исходный текст
Ответы Re: plpgsql: RAISE  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Lamar Owen
Дата:
Сообщение: Re: Re: RPM source files should be in CVS (was Re: [GENERAL] psql -l)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Large queries - again...