RE: When malloc returns zero ...
От | Hiroshi Inoue |
---|---|
Тема | RE: When malloc returns zero ... |
Дата | |
Msg-id | 001601bfb4c2$a3f71f80$2801007e@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: When malloc returns zero ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > >> (BTW, I actually think that the current approach is more robust than > >> exception catchers for modules that are part of the standard system; > >> it forces on you the discipline of making sure that all recoverable > >> resources are tracked in data structures less transient than some > >> routine's local variables. > > > Hmm,for the query SELECT .. FROM .. WHERE int2key = 1; > > we coudn't try to convert 1 -> 1::int2 because the conversion may > > cause elog(ERROR). Isn't it too restrictive ? > > Well, that's not a particularly good example, because it wouldn't > be hard at all for us to avoid reducing "int2var = 32768::int4" > to "int2var = 32768::int2" (oops). Hmm,am I misunderstanding ? As for conversion functions,shouldn't they return return-code unless they could throw "catchable" exceptions ? If the conversion 32768::int4 -> 32768::int2 returns an error we would be able to find that "int2var = 32768::int4" is always false. If I recognize correctly,"catchable" exceptions means that we could catch them if we want(otherwise they are dealt with a default exception handler like current elog handler). So they would be same as elog() except the special cases we are interested in. Where are problems when we handle conversion functions with return code or "catchable" exceptions ? Regards. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: