Re: Advice on stored proc error handling versus Sybase? - Mailing list pgsql-novice

From Ken Corey
Subject Re: Advice on stored proc error handling versus Sybase?
Date
Msg-id 3A5AFD7E.67014B9A@kencorey.com
Whole thread Raw
In response to Advice on stored proc error handling versus Sybase?  (Ken Corey <ken@kencorey.com>)
Responses Re: Re: Advice on stored proc error handling versus Sybase?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-novice
Thanks for the response, Tom.

Tom Lane wrote:
> We don't have default arguments for functions --- that wouldn't interact
> too well with function-name overloading (which is the feature whereby

Right.  Not what I'm used to, but I'll get over it.  *smile*.  So that
means that when calling a function using nulls, I have to cast the nulls
to an appropriate type so that plpgsql can figure out which function I
mean...messy.

> > 3) What if the insert fails?  How can I tell?
>
> You don't have to, because the function won't get to execute any further
> if there's an error.  AFAIK there's not yet any provision for trapping
> errors in plpgsql.  You might want to try the select first, and only
> do the insert if the select doesn't find a match.

Hrm...I must be able to tell *somewhere* that an error happened,
otherwise how would you ever know if something is wrong or not?  I mean,
okay, the referential validity may have been maintained, but that's
scant consolation when the data just can't be inserted and I can't see
why.

Can you tell in the sql/C/whatever that called the plpgsql function?  Do
you get a return code back indicating '*some* error happened'?

-Ken

pgsql-novice by date:

Previous
From: Tom Lane
Date:
Subject: Re: Advice on stored proc error handling versus Sybase?
Next
From: Andy Holman
Date:
Subject: Days betwen dates