From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tels <nospam-pg-abuse(at)bloodgate(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Declaring a strict function returns not null / eval speed |
Date: | 2019-10-22 19:18:45 |
Message-ID: | 20191022191845.GC4495@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Re: Tom Lane 2019-10-22 <821(dot)1571771210(at)sss(dot)pgh(dot)pa(dot)us>
> 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.
Or require superuser.
> This doesn't seem too awful to me, because non-builtin functions are
> most likely slow enough that it doesn't matter.
Some years ago, Kohsuke Kawaguchi, the Jenkins author, was giving a
keynote at FOSDEM about extensibility of software. The gist I took
away from it was the tagline "if core can do something that extensions
can't, that's a bug". I think that's something that PostgreSQL should
try to live up to as well.
Christoph
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-10-22 19:43:13 | Re: Declaring a strict function returns not null / eval speed |
Previous Message | Tom Lane | 2019-10-22 19:06:50 | Re: Declaring a strict function returns not null / eval speed |