Re: 8.1 system info / admin functions

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

In response to

Browse pgsql-hackers by date

  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