Re: Declaring a strict function returns not null / eval speed

Hi,

On 2019-10-22 15:06:50 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2019-10-20 10:27:19 -0400, Tom Lane wrote:
> >> "RETURNS NOT NULL", perhaps? That'd have the advantage of not requiring
> >> any new keyword.
>
> > That could work.
>
> Actually, I think we probably don't need any SQL representation of this
> at all, because if what you're going to do with it is omit logically
> necessary null-value checks, then a wrong setting would trivially crash
> the server. Therefore, we can never give the ability to set this flag
> to users; we could only set it on built-in functions.

I assumed we'd allow it plainly for C functions, as there's already
myriad ways to break the server. And for anything but C, we probably
should check it in the language handler (or some generic code invoking
that).

I think it's interesting to have this function property not just for
performance, but also semantic reasons. But it's fine to include the
check in the function handler (or some wrapper around those, if we think
that's worthwhile), rather than relying on the function to get this
right.

> This doesn't seem too awful to me, because non-builtin functions are
> most likely slow enough that it doesn't matter.

With builtin, do you mean just internal functions, or also "C"? I think
it's worthwhile to allow "C" directly if benchmarks proves this is
worthwhile.

Greetings,

Andres Freund