Re: [PATCHES] plpgsql raise - parameters can (ToDo)
> Our experience in writing the backend is that hard-wiring a single error > message text for a SQLSTATE code is the wrong thing. The SQLSTATE codes > are relatively coarse-grained (which is usually the right thing from the > perspective of an application trying to match a SQLSTATE) and there is > very often room for the text message to give more detail than the > SQLSTATE alone conveys. I can define more user's exceptions. And every can have own message text. It's personal preference. I prefere one exception, one parametrized message text. It's not important on procedure level. But If can be possible define exceptions for schema, then I can share message texts. > > Also, the above seems highly error prone to me since it decouples the > format string from the parameters. This is even worse for built-in > exception codes since the writer of a plpgsql function shouldn't assume > that he knows exactly what % parameters a built-in exception's format > string would use. Yes, it's can be source of errors. But I can check it in compile time (not now, or after apply patch (if will be). > > So for all these reasons, I think that only the SQLSTATE should be > associated with the exception name. The format string should be part > of the RAISE command. > my ideas are only proposal. Nothing more. What I think is important o using expr in raise params o set SQLSTATE for better diagnostic o raising system's exceptions all next is unnecessary luxus. But the idea EXCEPTION's variable is good, and can be easy evolved. Regards Pavel Stehule ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] plpgsql raise - parameters can (ToDo)
Pavel Stehule <[EMAIL PROTECTED]> writes: > declare myexcept exception = 'x'; > begin; > assoc(myexcept, 'my message % % %'); > raise myexcept, param1, param2, ... Our experience in writing the backend is that hard-wiring a single error message text for a SQLSTATE code is the wrong thing. The SQLSTATE codes are relatively coarse-grained (which is usually the right thing from the perspective of an application trying to match a SQLSTATE) and there is very often room for the text message to give more detail than the SQLSTATE alone conveys. Also, the above seems highly error prone to me since it decouples the format string from the parameters. This is even worse for built-in exception codes since the writer of a plpgsql function shouldn't assume that he knows exactly what % parameters a built-in exception's format string would use. So for all these reasons, I think that only the SQLSTATE should be associated with the exception name. The format string should be part of the RAISE command. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] plpgsql raise - parameters can (ToDo)
> 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.) There is space for future version. I think for todo for plpgsql o rethrow exception in exception handler block o user defined exceptions o mapping user's exception on system's exception My previous mail isn't correct. I need somewhere specify errmsg text, and ofcourse params. ??? declare myexcept exception = 'x'; begin; assoc(myexcept, 'my message % % %'); raise myexcept, param1, param2, ... default level of user exception is exception. regards Pavel Stehule ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
