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
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 |