From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 8.1 system info / admin functions |
Date: | 2005-09-14 06:33:25 |
Message-ID: | 4327C435.5010608@samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> I agree with both of those criticisms: total is more in line with our
> nomenclature than complete, and the other functions should return void
> and ereport when they are unhappy. (Saying "I failed" and not having
> any mechanism to report why sucks.)
From reading the code, it suggests that one reason these functions
don't elog on error is that they are intended to be used in loops, and
that a particular function call might fail for some harmless reason
(e.g. because the backend you're trying to cancel has already exited on
its own). So if you're doing "SELECT pg_cancel_backend(backend_pid),
backend_pid FROM list_of_backends", you might not want to abort the
entire query if a particular pg_cancel_backend() fails.
I'm not convinced: return codes are ugly, and savepoints and PL/PgSQL
exceptions can be used to avoid aborting the entire current transaction
if a particular function call fails. Or the above loop can just be done
on the client-side.
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paesold | 2005-09-14 06:36:52 | Bug with cursor declaration in plpgsql? (Repost) |
Previous Message | Neil Conway | 2005-09-14 05:37:51 | Re: 8.1 system info / admin functions |