Re: plpgsql raise - parameters can be expressions

From: Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: plpgsql raise - parameters can be expressions
Date: 2005-06-13 07:16:28
Message-ID: Pine.LNX.4.44.0506130837190.17363-100000@kix.fsv.cvut.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


> I don't see an easy way to get around this, though, and it's not too
> concerning. Amusingly it does completely break the SQLSTATE and SQLERRM
> tests we added a few days ago :)

Yes, it's true. But with simple plpgsql parser isn't possible expect
miracles :). I think so there is some space for modifications -
read_sql_construct - add control for availability sql params. You can
solve all errors where is expr_until_semi.

This is exactly same situation like

create function ...
begin
execute 'select '||a;
end; $$

it generate runtime error

>
> BTW, another easy improvement in this area is changing the RAISE format
> string to allow it to be an expression, rather than only a string literal.
>

No problem. But it's maybe big change. And I don't see using format string
too much limiting.

Pavel

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2005-06-13 12:01:04 Re: plpgsql raise - parameters can be expressions
Previous Message Neil Conway 2005-06-13 06:37:42 Re: psql: make \x affect normal queries only