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