Re: ISSTRICT behavior

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...