Re: ISSTRICT behavior
От | Don Y |
---|---|
Тема | Re: ISSTRICT behavior |
Дата | |
Msg-id | 4459B0BE.40902@DakotaCom.Net обсуждение исходный текст |
Ответ на | Re: ISSTRICT behavior (Martijn van Oosterhout <kleptog@svana.org>) |
Список | pgsql-general |
Martijn van Oosterhout wrote: > On Thu, May 04, 2006 at 12:19:12AM -0700, Don Y wrote: >> I'm not designing for the "traditional" role that you're >> used to so I can do whatever makes sense for this product >> and just *define* that as it's behavior. Since there are >> no other products that compete with it, users don't >> really have much choice! :> > > You can do what you like, however, it's still not clear to me what you > think the problem is. If you want your functions to be declared STRICT, > provide a .sql file that does that. It you want to program defensivly > and not crash if the user declares the function without STRICT, add: > > if( PG_ARGISNULL(...) ) > PG_RETURN_NULL(); But, this means anything that invokes the function has to be ready to handle a NULL returned *from* this function. > Which has exactly the same effect. That was my original question. I don't think it *is* the same. If you declare STRICT, the function never gets invoked! If you use PG_ARGISNULL, the function *has* been invoked and (the subject of another of my questions), all I can do is issue a message -- but I can't stop the rest of the execution: SELECT nonstrict(another(...)) ... Nonstrict() has been defined to expect an INT (e.g.). I.e. that's how it *should* be defined. If another() is misdeclared as not STRICT (because the user is not the one who wrote the actual *code* for it) and happens to be invoked with NULL, then it *can* detect that it has been invoked with NULL (PG_ARGISNULL) and it can issue an error message. But, it will have to return an INT (*not* NULL) otherwise Nonstrict will complain (crash?) when it sees the NULL *result* from the another() invocation. If, instead, another() could see the NULL passed to *it*, issue an error and then *abort* the "process" that is running the SELECT... This would be more in line with how the SELECT would operate if another() *had* been properly declared as STRICT yet invoked with NULL! (Or, have I misunderstood something?) Ditto: SELECT another_function(...) + another_function(...) ... > Of course, users could screw up the > data-types also so you could, if you wanted, add more code to check the > datatypes passed. > > Fact is, if the user has superuser priveledges, they can create C > functions any way they like. If you want to protect from that you need > to add stuff to your C function. I'm not worried about the folks writing the actual C code. What I am worried about is the folks who use the wrong .sql to CREATE FUNCTION... It may be best (for me) to just cut this capability out completely...
В списке pgsql-general по дате отправления: