Re: 8.1 system info / admin functions

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

In response to

Browse pgsql-hackers by date

  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