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
