Re: ISSTRICT behavior
От | Don Y |
---|---|
Тема | Re: ISSTRICT behavior |
Дата | |
Msg-id | 4459AD5A.9010708@DakotaCom.Net обсуждение исходный текст |
Ответ на | Re: ISSTRICT behavior (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ISSTRICT behavior
|
Список | pgsql-general |
Tom Lane wrote: > Don Y <pgsql@DakotaCom.Net> writes: >> First, if the function is defined to return an INT16, >> then returning a NULL doesn't make any sense -- since the >> caller doesn't know how to deal with a NULL (it expects >> an INT16, for example). > > Really? That would be a caller bug, if it's calling a function > that might return NULL. The function wouldn't be expected (nor defined!) to return NULL. So, if it was INVOKED with a NULL, it could *detect* that and issue an error message. But, it could NOT do PG_RETURN_NULL since the caller(s) wouldn't be expecting a NULL return value (why complicate every routine by forcing them all to handle NULLs?). Hence my comment that I would have to pick some generic (insignificant) value that was consistent with the return type of the function and pass that along. OTOH, if the function could *abort* it's invocation, then I don't have to worry about return values. It is a closer model to the STRICT behavior -- instead of aborting the function invocation BEFORE (which STRICT essentially does), I could abort it AFTER invocation (once I had detected the NULL argument) >> What I am trying to do is make functions more robust. >> As it stands currently, the functions get written and >> compiled "once". Thereafter, someone can FAIL to >> specify STRICT when creating those functions in SQL >> (CREATE FUNCTION...) and leave the server vulnerable >> to having those functions invoked with NULL arguments. > > This would be the error of the person specifying the function's > SQL definition. Since there are many ways to crash the system by > writing a C function definition wrongly (eg, give the wrong > datatypes), I can't get very excited about this particular one. > We do make this a superuser-only feature for a reason: you're > expected to be competent enough to get it right. So, it might be more prudent to build the functions that are needed and then just prevent other functions from being added at all! That's a relatively easy parser hack...
В списке pgsql-general по дате отправления: