On Tue, Oct 24, 2017 at 4:36 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Does it? In plenty of cases getting infinity rather than an error is >> just about as useful. >> This was argued by a certain Tom Lane a few years back ;) >> http://archives.postgresql.org/message-id/19208.1167246902%40sss.pgh.pa.us > > Yeah, but I lost the argument. For better or worse, our expected > behavior is now that we throw errors. You don't get to change that > just because it would save a few cycles.
I don't know that we can consider the results of a discussion in 2006 to be binding policy for the indefinite future. A lot of things get relitigated more than once per decade on this mailing list, and if we know things now that we didn't know then (e.g. that one choice has a far more severe performance consequence than the other) that's reasonable justification for deciding to change our mind. Also, it's not like there were a million votes on one side vs. just you on the other; reading the thread, it's not at all clear that you were in the minority with that position. That's not to say I necessarily support Andres's proposal. Changing query behavior is a big deal; we can't do it very often without causing a lot of hassles for users (and maybe damaging our reputation for stability in the process). And it's not very clear to me that someone who does a SUM(a * b) over many rows will be happy to get infinity rather than an error. It could be true, but I don't have the experience to be sure of it -- and I'm a bit worried that if we change anything, we'll only find out whether users like it after we cut the release. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
