Re: 8.1 system info / admin functions - Mailing list pgsql-hackers

From Neil Conway
Subject Re: 8.1 system info / admin functions
Date
Msg-id 4327C435.5010608@samurai.com
Whole thread Raw
In response to Re: 8.1 system info / admin functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: 8.1 system info / admin functions
Next
From: "Michael Paesold"
Date:
Subject: Bug with cursor declaration in plpgsql? (Repost)