On 1/5/17, Tom Lane <t...@sss.pgh.pa.us> wrote: > Vitaly Burovoy <vitaly.buro...@gmail.com> writes: >>> I've written a patch which fixes that bug (in attachment). >>> Should it be registered in the CF? > >> Oops. Forgot to attach the patch. Fixed. > > I suspect that many of these SAMESIGN() tests you've added are not > actually adequate/useful. That's only sufficient when the output could be > at most a factor of 2 out-of-range. If it could overflow past the sign > bit then you need to work harder.
I disagree. These SAMESIGN() tests cover addition where result can not be more than one out-of-range. Multiplications are covered just before. > (By the same token, the existing SAMESIGN test in interval2tm is > wrong.) > > Possibly we should consider alternatives before plowing ahead in this > direction, since adding guards to interval_in and interval computations > doesn't help with oversize values that are already stored in a database. We can do nothing with values are already stored in a database. But we can prevent appearing them later. > We could think about replacing interval2tm's output format with some > other struct that uses a TimeOffset for hours and so cannot overflow. > I'm not sure though how far the effects would propagate; it might be > more work than we want to put into this. If values with overflow are already in a database, what do you expect a new output function should fix? -- Best regards, Vitaly Burovoy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
