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

From Andreas Pflug
Subject Re: 8.1 system info / admin functions
Date
Msg-id 4327DCF1.2080709@pse-consulting.de
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:
> Neil Conway <neilc@samurai.com> writes:
> 
>>(2) pg_cancel_backend(), pg_reload_conf(), and pg_rotate_logfile() all 
>>return an int indicating success (1) or failure (0). Why shouldn't these 
>>functions return a boolean?

I would have used boolean as return code for success and failure, but 
the previously existing pg_cancel_backend did return int so I matched 
that behaviour.

> 
>>(Presumably there is a good reason why these functions return a status 
>>code at all, rather than aborting via elog on error -- right?)
> 
> 
> 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.)

These functions will only handle being called from a non-superuser as 
fatal error, failures from normal executions (i.e. returning 0) will 
give an elog WARNING and thus complete report about the cause, if needed.

Nonexecution of these functions isn't really a problem (and not 
synchronizable in transactions for following statements anyway), OTOH 
having to deal with errors in the client that could be safely ignored or 
add savepoints sounds like overkill and a solution for a non-problem.

Regards,
Andreas


pgsql-hackers by date:

Previous
From: "Michael Paesold"
Date:
Subject: Re: postgresql CVS callgraph data from dbt2
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Spinlocks, yet again: analysis and proposed patches