On 07/31/04:30/6, Tom Lane wrote: > Is there any actual functional usefulness to that, or is it just to > avoid having to reorder existing code to fit into the try/catch paradigm? Both, I imagine. In the case of the former, it *may be* useful for someone to create their own paradigm, which seems like it would tye back into the latter.
> I would actually prefer to force people to use the try/catch macros, in > the name of code readability and consistent coding style. Ah, you must be a Python programmer at heart! ;) > I had never > felt that I understood the way the plpython error-trapping code was > structured, until I had to go in and examine it in detail to rewrite it > into the try/catch style. Yeah, it wasn't pretty. When I first started on plpy, I hadn't even heard of sigjmp_buf before. Perhaps you can imagine the clumps of hair I had to pull out to finally get a grasp on it. > I think it's now a lot more legible to the > casual reader, and that's an important goal for Postgres-related code. Definitely. It is a vast improvement over plpython's more demanding style. > If you're really intent on doing that, you probably can do it no matter > what I say about it ;-). I have yet to decide to adopt the new syntax, as I just saw it yesterday, but it is likely that I will, as I do depend on PG, so if it convenient, I might as well use the tools that it gives me. > But I find it hardly any improvement over > direct use of the setjmp API. Well, I find it more aesthetically appealing, and it can be quite nice to have a macro interface to allow the underlying to change willy-nilly(not that it should, but that it can). I'll bet that's the "hardly any improvement" that you mentioned. -- Regards, James William Pye
pgp1kRiCAv5XB.pgp
Description: PGP signature