Re: Advice on stored proc error handling versus Sybase?
| От | Ken Corey |
|---|---|
| Тема | Re: Advice on stored proc error handling versus Sybase? |
| Дата | |
| Msg-id | 3A5AFD7E.67014B9A@kencorey.com обсуждение исходный текст |
| Ответ на | Advice on stored proc error handling versus Sybase? (Ken Corey <ken@kencorey.com>) |
| Ответы |
Re: Re: Advice on stored proc error handling versus Sybase?
|
| Список | 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 по дате отправления: