From: | Ken Corey <ken(at)kencorey(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: Advice on stored proc error handling versus Sybase? |
Date: | 2001-01-09 12:01:02 |
Message-ID: | 3A5AFD7E.67014B9A@kencorey.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general 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
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2001-01-09 12:16:46 | Re: Re: Loading optimization |
Previous Message | Jarmo Paavilainen | 2001-01-09 11:49:29 | SV: shutting down postmasters |
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Holman | 2001-01-09 16:18:44 | Days betwen dates |
Previous Message | Tom Lane | 2001-01-09 06:36:04 | Re: Advice on stored proc error handling versus Sybase? |