From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: plpgsql raise - parameters can be expressions |
Date: | 2005-06-13 14:08:33 |
Message-ID: | 19378.1118671713@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Neil Conway <neilc(at)samurai(dot)com> writes:
> BTW, one regression is that an undefined variable in the RAISE list is
> no longer a compile-time error:
> ...
> 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 :)
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 ...
> 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.
I would sort of have expected this to get done at the same time.
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: it
desperately needs to be fixed so that you can specify the SQLSTATE to
be thrown, and so that you can re-throw the same exception you caught.
(Note that SQLERRM is not really a solution to that: you might think
something like "RAISE EXCEPTION SQLSTATE, '%', SQLERRM" would do,
but it loses information, namely all the auxiliary fields.)
Ideas?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2005-06-13 16:37:42 | Re: plpgsql raise - parameters can be expressions |
Previous Message | Atsushi Ogawa | 2005-06-13 13:15:14 | EUC_JP and SJIS conversion improvement |