Re: C Language Stored Procedure Returning No Data - Mailing list pgsql-general

From Michael Fuhr
Subject Re: C Language Stored Procedure Returning No Data
Date
Msg-id 20060203172954.GA61283@winnie.fuhr.org
Whole thread Raw
In response to Re: C Language Stored Procedure Returning No Data  (Jeff Trout <threshar@torgo.978.org>)
List pgsql-general
On Fri, Feb 03, 2006 at 09:07:48AM -0500, Jeff Trout wrote:
> On Feb 2, 2006, at 7:17 PM, Michael Fuhr wrote:
> >If you declare the function with "RETURNS bytea" then the function
> >must return something; if zero-length data and NULL aren't suitable
> >for indicating no data then you could raise an error and catch that
> >error in the client.  Another possibility would be to make the
> >function set-returning ("RETURNS SETOF bytea" and some code changes)
> >and return no rows to indicate no data.
>
> Another possibility is to log an exception with elog & company.

That's what I meant by "raise an error."  Incidentally, for user-
visible messages ereport is preferred over "its older cousin" elog
(perhaps ereport is what you meant by "& company").

http://www.postgresql.org/docs/8.1/interactive/error-message-reporting.html

"Therefore, elog should be used only for internal errors and low-level
debug logging.  Any message that is likely to be of interest to
ordinary users should go through ereport."

> However that will also have the side effect of rolling back the txn
> if you are currently in one.

In 8.0 and later you could wrap the function call with a savepoint,
explicitly or implicitly (e.g., via an EXCEPTION clause in a PL/pgSQL
function).  Exception-handling code in the caller could roll back
to the savepoint if an error is raised.

--
Michael Fuhr

pgsql-general by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Primary keys for companies and people
Next
From: "Uwe C. Schroeder"
Date:
Subject: Re: PgSQL as part of commercial product