From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 8.1 system info / admin functions |
Date: | 2005-09-14 08:18:57 |
Message-ID: | 4327DCF1.2080709@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2005-09-14 08:25:09 | Re: Spinlocks, yet again: analysis and proposed patches |
Previous Message | Michael Paesold | 2005-09-14 08:01:30 | Re: postgresql CVS callgraph data from dbt2 |