Re: Re: Advice on stored proc error handling versus Sybase?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ken(at)kencorey(dot)com
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: Re: Advice on stored proc error handling versus Sybase?
Date: 2001-01-09 17:05:16
Message-ID: 1320.979059916@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-novice

Ken Corey <ken(at)kencorey(dot)com> writes:
> 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.

Only if there's not enough information in the other arguments to
uniquely determine which function you mean.

>>>> 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?

Well, your application gets back an error message, but my point was that
the code of the function itself doesn't get to trap the error. (Yes,
this could stand to be improved.)

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2001-01-09 17:11:58 Re: ECPG could not connect to the database.
Previous Message Matthew Kennedy 2001-01-09 16:49:49 is there a vendor independent C API for DB development?

Browse pgsql-novice by date

  From Date Subject
Next Message John Burski 2001-01-09 21:15:50 Comparison Operator problem
Previous Message Andy Holman 2001-01-09 16:18:44 Days betwen dates