On Fri, Dec 14, 2018 at 9:11 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Isaac Morland <isaac.morl...@gmail.com> writes: > > I would be interested if you have an example where the ability of > > date/timestamp values to be infinite adds special case coding. > > I think Robert is talking about the implementation functions for > timestamp-related operations, which typically do have to special-case > infinite inputs. I take your point that there might be fewer special > cases in the calling SQL code, though.
Exactly. And now that we have JIT compilation, the overhead of such cases in more worth considering than previously. To take a related example, int4pl() can be reduced to a single instruction if you ignore overflow -- but you can't ignore overflow, which means you needs some more instructions to handle the overflow case, which means that the number of instructions is actually increasing quite a bit. Without JIT, maybe that's not too noticeable because you've got to pay the cost of setting up a stack frame for the function and tearing it down, but JIT can optimize those costs away. So essentially I think supporting special values like infinity boils down to trading away some small amount of performance -- more likely to be noticeable with JIT -- for some amount of possible programmer convenience. Some people may think that's a good trade, and other people may not like it. It just depends on whether the 'infinity' value is useful to you. If it is, you'll probably like the trade, because aside from the notational cost which Isaac mentioned, it's probably vastly faster to handle the infinity values in C code than to stick CASE..WHEN in to an SQL query. If it's not, you may dislike it. If your application code now has to know about the possibility 'infinity' value that it otherwise wouldn't have to worry about, you may dislike it for that reason also. I'm not sure there's one right answer here - my personal feeling is that infinite values are a wart, but I grant Isaac's point that they can sometimes simplify SQL coding. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
