On Tue, May 06, 2014 at 12:18:02PM -0700, Jeff Davis wrote:
> On Tue, 2014-05-06 at 14:48 -0400, Tom Lane wrote:
> > However, removing *any* digits seems like it mostly defeats the point of
> > the test. Maybe we should just lose the test?
>
> The reason I thought it might still have some value is because it would
> have still caught the problem that 4318daec patched. But I'm fine with
> removing it.
>
> (Though, I should add a comment indicating that it's not testing the
> true maximum length.)
I'm good with how you fixed it; losing three digits wouldn't be grave. I
might fix it like this instead:
--- a/src/test/regress/sql/interval.sql
+++ b/src/test/regress/sql/interval.sql
@@ -111,3 +111,5 @@ select '4 millenniums 5 centuries 4 decades 1 year 4 months 4 days 17 minutes 31
-- test long interval output
-select '100000000y 10mon -1000000000d -1000000000h -10min -10.000001s ago'::interval;
+select '100000000y 10mon -1000000000d -1000000000h -10min -10.000001s ago'::interval::text IN
+('@ 100000000 years 10 mons -1000000000 days -1000000000 hours -10 mins -10.000001 secs ago',
+ '@ 100000000 years 10 mons -1000000000 days -1000000000 hours -10 mins -10 secs ago');
It seems I also broke the ecpg test suite under --disable-integer-datetimes.
I think (not tested) the fix is s/123456789/123456123/ in dt_test2.pgc,
because it rounds under float datetimes and truncates under integer datetimes.
> > A different solution is to add a variant expected-output file, though
> > I'm not terribly thrilled with that answer.
>
> Nor am I.
Agreed.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
