Re: proposal: rounding up time value less than its unit.

From: Gregory Smith <gregsmithpgsql(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: rounding up time value less than its unit.
Date: 2014-09-28 01:12:13
Message-ID: 5427606D.1070103@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/26/14, 3:22 PM, Tom Lane wrote:
> We could alternatively try to split up these cases into multiple GUCs,
> which I guess is what you're imagining as a "multi-year battle".

No, I was just pointing out that even the cleanest major refactoring
possible here is going to result in broken config files complaints for
years. And no matter how well that goes, a second rewrite in the next
major version, addressing whatever things nobody saw coming in the first
redesign, is a very real possibility. The minute the GUC box is opened
that far, it will not close up again in a release, or likely even two,
and the griping from the field is going to take 3+ years to settle.

I have no desire to waste time on partial measures either though. I
think I've been clear that's my theme on this--if we're gonna mess with
this significantly, let's do it right and in a big way. If there's a
really trivial fix to apply, that's fine too. Throw an error when the
value is between the special one and the useful minimum, no other
changes; that I could see slipping into a single release without much
pain. Might even be possible to write as a useful sub-step toward a
bigger plan too. Wouldn't bother breaking that out as a goal unless it
just happened to fall out of the larger design though.

The rest of the rounding and error handling ideas wandering around seem
in this uncomfortable middle ground to me. They are neither large
enough to feel like a major improvement happened, nor trivial enough to
apply with minimal work/risk. And this is not a bug that must be fixed
ASAP--it's an unfriendly UI surprise.

--
Greg Smith greg(dot)smith(at)crunchydatasolutions(dot)com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Smith 2014-09-28 01:22:25 Re: Last Commitfest patches waiting review
Previous Message Andrew Dunstan 2014-09-27 23:58:43 Re: json (b) and null fields