On Fri, Jul 30, 2021 at 03:03:13PM -0400, Bruce Momjian wrote:
> > On output, the months field is shown as an appropriate number of
> > years and months; the days field is shown as-is; the microseconds
> > field is converted to hours, minutes, and possibly-fractional
> >
Bruce Momjian writes:
> On Fri, Jul 30, 2021 at 03:54:42PM -0400, Tom Lane wrote:
>> Having said that, I also agree that it's not great that '1.4 years'
>> is converted to '1 year 4 mons' (1.3... years) rather than
>> '1 year 5 mons' (1.41666... years). The latter seems like a clearly
>>
On Fri, Jul 30, 2021 at 03:54:42PM -0400, Tom Lane wrote:
> Having said that, I also agree that it's not great that '1.4 years'
> is converted to '1 year 4 mons' (1.3... years) rather than
> '1 year 5 mons' (1.41666... years). The latter seems like a clearly
> saner translation. I would
On Fri, Jul 30, 2021 at 03:47:53PM -0400, Robert Haas wrote:
> On Fri, Jul 30, 2021 at 3:20 PM Bruce Momjian wrote:
> > Uh, what do you suggest then? You wanted the years/months fixed, and
> > rounding at spill stop time makes sense, and fixes the problem.
>
> Hmm, maybe I misunderstood. Are
Bruce Momjian writes:
> On Fri, Jul 30, 2021 at 03:08:56PM -0400, Robert Haas wrote:
>> Just to be clear, I am against this patch. I don't think it's a
>> minimal change for the reported problem, and I think some people will
>> be unhappy about the behavior changes.
> Uh, what do you suggest
On Fri, Jul 30, 2021 at 3:20 PM Bruce Momjian wrote:
> Uh, what do you suggest then? You wanted the years/months fixed, and
> rounding at spill stop time makes sense, and fixes the problem.
Hmm, maybe I misunderstood. Are you saying that you think the patch
will fix cases like interval '-1.7
On Fri, Jul 30, 2021 at 03:08:56PM -0400, Robert Haas wrote:
> On Fri, Jul 30, 2021 at 3:03 PM Bruce Momjian wrote:
> > Here is an updated patch that includes some of your ideas.
>
> Just to be clear, I am against this patch. I don't think it's a
> minimal change for the reported problem, and I
On Fri, Jul 30, 2021 at 3:03 PM Bruce Momjian wrote:
> Here is an updated patch that includes some of your ideas.
Just to be clear, I am against this patch. I don't think it's a
minimal change for the reported problem, and I think some people will
be unhappy about the behavior changes.
--
On Fri, Jul 30, 2021 at 12:49:34PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Now that I think of it, I will just remove the word "rounded" from the
> > back branch docs so we are technically breaking the documented API less
> > in PG 15.
>
> I think your first idea was better. Not
Bruce Momjian writes:
> On Fri, Jul 30, 2021 at 12:04:39PM -0400, Bruce Momjian wrote:
>> Unless I hear more feedback, I plan to apply this doc patch to all
>> branches with the word "rounded" changed to "truncated" in the back
>> branches, and apply the rounded code changes to master.
> Now
On Fri, Jul 30, 2021 at 12:04:39PM -0400, Bruce Momjian wrote:
> On Wed, Jul 28, 2021 at 11:19:16AM -0400, Bruce Momjian wrote:
> > On Wed, Jul 28, 2021 at 08:42:31AM +0100, Dean Rasheed wrote:
> > > So it's equal even without calling justify_interval() on the result.
> > >
> > > FWIW, I remain
On Wed, Jul 28, 2021 at 11:19:16AM -0400, Bruce Momjian wrote:
> On Wed, Jul 28, 2021 at 08:42:31AM +0100, Dean Rasheed wrote:
> > So it's equal even without calling justify_interval() on the result.
> >
> > FWIW, I remain of the opinion that the interval literal code should
> > just spill down
Robert Haas writes:
> On Wed, Jul 28, 2021 at 1:05 PM Tom Lane wrote:
>> That would clearly be a bug fix. I'm just troubled that there are
>> still behaviors that people will see as bugs.
> That's a reasonable thing to be troubled about, but the date and time
> related datatypes have so many
On Wed, Jul 28, 2021 at 1:05 PM Tom Lane wrote:
> Fair point, but you decided when you chose to use float that you don't
> care about the differences between numbers that only differ at the
> seventeenth or so decimal place. (Maybe, if you don't understand what
> float is, you didn't make that
Robert Haas writes:
> On Wed, Jul 28, 2021 at 11:52 AM Tom Lane wrote:
>> You know, I was thinking exactly that thing earlier. Changing the
>> on-disk representation is certainly a nonstarter, but the problem
>> here stems from expecting interval_in to do something sane with inputs
>> that do
On Wed, Jul 28, 2021 at 11:52 AM Tom Lane wrote:
> You know, I was thinking exactly that thing earlier. Changing the
> on-disk representation is certainly a nonstarter, but the problem
> here stems from expecting interval_in to do something sane with inputs
> that do not correspond to any
Robert Haas writes:
> If we were doing this over again, I would argue that, with this
> on-disk representation, 0.7 months ought to be rejected as invalid
> input, because it's generally not a good idea to have a data type that
> silently converts a value into a different value that is not
>
On Tue, Jul 27, 2021 at 4:02 PM Tom Lane wrote:
> What I think we have consensus on is that interval_in is doing the
> wrong thing in a particular corner case. I have heard nobody but
> you suggesting that we should start undertaking behavioral changes
> in other interval functions, and I don't
On Wed, Jul 28, 2021 at 08:42:31AM +0100, Dean Rasheed wrote:
> On Wed, 28 Jul 2021 at 00:08, John W Higgins wrote:
> >
> > It's nice to envision all forms of fancy calculations. But the fact is that
> >
> > '1.5 month'::interval * 2 != '3 month"::interval
> >
>
> That's not exactly true. Even
On Wed, Jul 28, 2021 at 12:42 AM Dean Rasheed
wrote:
> On Wed, 28 Jul 2021 at 00:08, John W Higgins wrote:
> >
> > It's nice to envision all forms of fancy calculations. But the fact is
> that
> >
> > '1.5 month'::interval * 2 != '3 month"::interval
> >
>
> That's not exactly true. Even without
On Wed, 28 Jul 2021 at 00:08, John W Higgins wrote:
>
> It's nice to envision all forms of fancy calculations. But the fact is that
>
> '1.5 month'::interval * 2 != '3 month"::interval
>
That's not exactly true. Even without the patch:
SELECT '1.5 month'::interval * 2 AS product,
'3
On Tue, Jul 27, 2021 at 3:36 PM Bryn Llewellyn wrote:
>
> with
> c1 as (
> select
> '1 month 1 day 1 second'::interval as i1,
> '1.234 month 1.234 day 1.234 second'::interval as i3),
>
> c2 as (
> select i1*1.234 as i2, i3 from c1)
>
> select i2::text as i2_txt, i3::text
> On 27-Jul-2021, at 14:13, Bruce Momjian wrote:
>
> On Tue, Jul 27, 2021 at 04:01:54PM -0400, Tom Lane wrote:
>> Bruce Momjian writes:
>>> I went ahead and modified the interval multiplication/division functions
>>> to use the same logic as fractional interval units:
>>
>> Wait. A. Minute.
>>
On Tue, Jul 27, 2021 at 04:01:54PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I went ahead and modified the interval multiplication/division functions
> > to use the same logic as fractional interval units:
>
> Wait. A. Minute.
>
> What I think we have consensus on is that interval_in
Bruce Momjian writes:
> I went ahead and modified the interval multiplication/division functions
> to use the same logic as fractional interval units:
Wait. A. Minute.
What I think we have consensus on is that interval_in is doing the
wrong thing in a particular corner case. I have heard
On Fri, Apr 2, 2021 at 09:02:29PM -0400, Bruce Momjian wrote:
> On Fri, Apr 2, 2021 at 05:50:59PM -0700, Bryn Llewellyn wrote:
> > are the user’s parameterization. All are real numbers. Because non-integral
> > values for years, months, days, hours, and minutes are allowed when you
> > specify
On Sun, Jul 25, 2021 at 11:56:54AM -0700, Bryn Llewellyn wrote:
> As far as I’ve been able, the PG documentation doesn’t do a good job of
> defining the semantics of any of these operations. Some (like the “justify”
This is because fractional interval values are not used or asked about
often.
>
> On 23-Jul-2021, br...@momjian.us wrote:
>
> On Fri, Jul 23, 2021 at 10:55:11AM -0700, Bryn Llewellyn wrote:
>> SELECT
>> '1.2345 months 1.2345 days 1.2345 seconds'::interval =
>> '1 month 1 day 1 second'::interval*1.2345;
>>
>> In 13.3, the result is TRUE. (I know that this doesn’t
On Fri, Jul 23, 2021 at 10:55:11AM -0700, Bryn Llewellyn wrote:
> SELECT
> '1.2345 months 1.2345 days 1.2345 seconds'::interval =
> '1 month 1 day 1 second'::interval*1.2345;
>
> In 13.3, the result is TRUE. (I know that this doesn’t guarantee that the
> internal representations of the two
> On 23-Jul-2021, at 08:05, Bruce Momjian wrote:
>
> On Thu, Jul 22, 2021 at 03:17:52PM -0700, Zhihong Yu wrote:
>> On Thu, Jul 22, 2021 at 2:59 PM Zhihong Yu wrote:
>>Hi,
>>
>>- tm->tm_mon += (fval * MONTHS_PER_YEAR);
>>+ tm->tm_mon += rint(fval
On Thu, Jul 22, 2021 at 03:17:52PM -0700, Zhihong Yu wrote:
> On Thu, Jul 22, 2021 at 2:59 PM Zhihong Yu wrote:
> Hi,
>
> - tm->tm_mon += (fval * MONTHS_PER_YEAR);
> + tm->tm_mon += rint(fval * MONTHS_PER_YEAR);
>
> Should the handling for
On Thu, Jul 22, 2021 at 2:59 PM Zhihong Yu wrote:
>
>
> On Wed, Jul 21, 2021 at 6:43 PM Bruce Momjian wrote:
>
>> On Wed, Jul 21, 2021 at 06:39:26PM -0700, Bryn Llewellyn wrote:
>> > Your statement
>> >
>> >
>> > “months-to-days conversion is almost always an approximation, while
>> the
>>
On Wed, Jul 21, 2021 at 6:43 PM Bruce Momjian wrote:
> On Wed, Jul 21, 2021 at 06:39:26PM -0700, Bryn Llewellyn wrote:
> > Your statement
> >
> >
> > “months-to-days conversion is almost always an approximation, while
> the
> > days to seconds conversion is almost always accurate.”
> >
>
On Wed, Jul 21, 2021 at 06:39:26PM -0700, Bryn Llewellyn wrote:
> Your statement
>
>
> “months-to-days conversion is almost always an approximation, while the
> days to seconds conversion is almost always accurate.”
>
>
> is misleading. Any conversion like these (and also the “spill
> On 21-Jul-2021, at 17:07, Bruce Momjian wrote:
>
> On Wed, Jul 21, 2021 at 01:29:49PM -0400, Tom Lane wrote:
>> Bryn Llewellyn writes:
>>> It was me that started the enormous thread with the title “Have I found an
>>> interval arithmetic bug?” on 01-Ap
On Wed, Jul 21, 2021 at 01:29:49PM -0400, Tom Lane wrote:
> Bryn Llewellyn writes:
> > It was me that started the enormous thread with the title “Have I found an
> > interval arithmetic bug?” on 01-Apr-2021. I presented this testcase:
>
> >>
> On 21-Jul-2021, at 01:23, Dean Rasheed wrote:
>
> On Wed, 21 Jul 2021 at 03:48, Bruce Momjian wrote:
>>
>> this example now gives me concern:
>>
>>SELECT INTERVAL '1.06 months 1 hour';
>> interval
>>---
>> 1 mon 2 days 01:00:00
>>
t is not indisputably
>> broken.
> It was me that started the enormous thread with the title “Have I found an
> interval arithmetic bug?” on 01-Apr-2021. I presented this testcase:
>> select interval '-1.7 years'; -- -1 years -8 m
-improvement.
>
> In general, considering that (most of?) the existing behavior has stood
> for decades, I think we need to tread VERY carefully about changing it.
> I don't want to see this patch changing any case that is not indisputably
> broken.
It was me that started the eno
Dean Rasheed writes:
> Hmm, looking at this whole thread, I have to say that I prefer the old
> behaviour of spilling down to lower units.
> For example, with this patch:
> SELECT '0.5 weeks'::interval;
> interval
> --
> 4 days
> which I don't think is really an improvement. My
On Wed, 21 Jul 2021 at 03:48, Bruce Momjian wrote:
>
> this example now gives me concern:
>
> SELECT INTERVAL '1.06 months 1 hour';
>interval
> ---
> 1 mon 2 days 01:00:00
>
> Notice that it rounds the '1.06 months' to '1 mon 2 days',
On Tue, Jul 20, 2021 at 05:13:37PM -0700, Zhihong Yu wrote:
> On Tue, Jul 20, 2021 at 3:53 PM Bruce Momjian wrote:
> With your patch, the following example (Coutesy Bryn) still shows fraction:
>
> # select (interval '1 month')*1.123;
> ?column?
> ---
> 1 mon 3 days
On Tue, Jul 20, 2021 at 3:53 PM Bruce Momjian wrote:
> On Tue, Jul 20, 2021 at 02:33:07PM -0700, Zhihong Yu wrote:
> > On Mon, Jul 19, 2021 at 9:14 PM Bruce Momjian wrote:
> > > Obviously this should return '1 mon 26 days', but with my most
> recent
> > > patch, it returned '1 mon 25
On Tue, Jul 20, 2021 at 02:33:07PM -0700, Zhihong Yu wrote:
> On Mon, Jul 19, 2021 at 9:14 PM Bruce Momjian wrote:
> > Obviously this should return '1 mon 26 days', but with my most recent
> > patch, it returned '1 mon 25 days'. Turns out I had not properly used
> > rint() in
On Mon, Jul 19, 2021 at 9:14 PM Bruce Momjian wrote:
> On Wed, Jul 14, 2021 at 09:03:21AM -0700, Zhihong Yu wrote:
> > On Thu, Jul 8, 2021 at 10:22 AM Zhihong Yu wrote:
> > On Wed, Jun 30, 2021 at 9:35 AM Bruce Momjian
> wrote:
> >
> > On Tue, Jun 29, 2021 at 06:49:45PM +0200,
On Wed, Jul 14, 2021 at 09:03:21AM -0700, Zhihong Yu wrote:
> On Thu, Jul 8, 2021 at 10:22 AM Zhihong Yu wrote:
> On Wed, Jun 30, 2021 at 9:35 AM Bruce Momjian wrote:
>
> On Tue, Jun 29, 2021 at 06:49:45PM +0200, Daniel Gustafsson wrote:
> > > On 29 Jun 2021, at 18:50,
On Thu, Jul 8, 2021 at 10:22 AM Zhihong Yu wrote:
>
>
> On Wed, Jun 30, 2021 at 9:35 AM Bruce Momjian wrote:
>
>> On Tue, Jun 29, 2021 at 06:49:45PM +0200, Daniel Gustafsson wrote:
>> > > On 29 Jun 2021, at 18:50, Zhihong Yu wrote:
>> >
>> > > Now that PG 15 is open for commit, do you think
On Wed, Jun 30, 2021 at 9:35 AM Bruce Momjian wrote:
> On Tue, Jun 29, 2021 at 06:49:45PM +0200, Daniel Gustafsson wrote:
> > > On 29 Jun 2021, at 18:50, Zhihong Yu wrote:
> >
> > > Now that PG 15 is open for commit, do you think the patch can land ?
> >
> > Adding it to the commitfest patch
On Tue, Jun 29, 2021 at 06:49:45PM +0200, Daniel Gustafsson wrote:
> > On 29 Jun 2021, at 18:50, Zhihong Yu wrote:
>
> > Now that PG 15 is open for commit, do you think the patch can land ?
>
> Adding it to the commitfest patch tracker is a good way to ensure it's not
> forgotten about:
>
>
> On 29 Jun 2021, at 18:50, Zhihong Yu wrote:
> Now that PG 15 is open for commit, do you think the patch can land ?
Adding it to the commitfest patch tracker is a good way to ensure it's not
forgotten about:
https://commitfest.postgresql.org/33/
--
Daniel Gustafsson
On Fri, May 7, 2021 at 7:42 PM Bruce Momjian wrote:
> On Fri, May 7, 2021 at 07:39:31PM -0700, Zhihong Yu wrote:
> >
> >
> > On Fri, May 7, 2021 at 7:23 PM Bruce Momjian wrote:
> >
> > On Fri, May 7, 2021 at 07:23:42PM -0700, Zhihong Yu wrote:
> > > On Tue, Apr 13, 2021 at 10:55 AM
On Fri, May 7, 2021 at 07:39:31PM -0700, Zhihong Yu wrote:
>
>
> On Fri, May 7, 2021 at 7:23 PM Bruce Momjian wrote:
>
> On Fri, May 7, 2021 at 07:23:42PM -0700, Zhihong Yu wrote:
> > On Tue, Apr 13, 2021 at 10:55 AM Bryn Llewellyn
> wrote:
> > There’s no shipped
On Fri, May 7, 2021 at 7:23 PM Bruce Momjian wrote:
> On Fri, May 7, 2021 at 07:23:42PM -0700, Zhihong Yu wrote:
> > On Tue, Apr 13, 2021 at 10:55 AM Bryn Llewellyn
> wrote:
> > There’s no shipped function that does this, and this makes me
> suspect that
> > I’d prefer to roll my own
On Fri, May 7, 2021 at 07:23:42PM -0700, Zhihong Yu wrote:
> On Tue, Apr 13, 2021 at 10:55 AM Bryn Llewellyn wrote:
> There’s no shipped function that does this, and this makes me suspect that
> I’d prefer to roll my own for any serious purpose.
>
> The existence of the three
On Tue, Apr 13, 2021 at 10:55 AM Bryn Llewellyn wrote:
> On 12-Apr-2021, at 17:25, Bruce Momjian wrote:
>
> On Mon, Apr 12, 2021 at 05:20:43PM -0700, Bryn Llewellyn wrote:
>
> I’d argue that the fact that this:
>
> ('0.3 months'::interval) + ('0.7 months'::interval)
>
> Is reported as '30 days'
> On 12-Apr-2021, at 17:25, Bruce Momjian wrote:
>
> On Mon, Apr 12, 2021 at 05:20:43PM -0700, Bryn Llewellyn wrote:
>> I’d argue that the fact that this:
>>
>> ('0.3 months'::interval) + ('0.7 months'::interval)
>>
>> Is reported as '30 days' and not '1 month' is yet another
>> bug—precisely
On Mon, Apr 12, 2021 at 4:22 PM Bruce Momjian wrote:
> On Mon, Apr 12, 2021 at 03:09:48PM -0700, Bryn Llewellyn wrote:
> > I showed you all this example a long time ago:
> >
> > select (
> > '
> > 3.853467 years
> > '::interval
> > )::text as i;
> >
> > This behavior is the same
On Mon, Apr 12, 2021 at 05:20:43PM -0700, Bryn Llewellyn wrote:
> I’d argue that the fact that this:
>
> ('0.3 months'::interval) + ('0.7 months'::interval)
>
> Is reported as '30 days' and not '1 month' is yet another
> bug—precisely because of what I said in my previous email (sorry
> that I
> On 12-Apr-2021, at 17:00, Bruce Momjian wrote:
>
> On Mon, Apr 12, 2021 at 07:38:21PM -0400, Tom Lane wrote:
>> Bruce Momjian writes:
>>> On Mon, Apr 12, 2021 at 03:09:48PM -0700, Bryn Llewellyn wrote:
After all, you've bitten the bullet now and changed the behavior. This
means
> t...@sss.pgh.pa.us wrote:
>
> br...@momjian.us writes:
>> b...@yugabyte.com wrote:
>>> After all, you've bitten the bullet now and changed the behavior. This
>>> means that the semantics of some extant applications will change. So... in
>>> for a penny, in for a pound?
>
>> The docs now say:
On Mon, Apr 12, 2021 at 07:38:21PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Apr 12, 2021 at 03:09:48PM -0700, Bryn Llewellyn wrote:
> >> After all, you've bitten the bullet now and changed the behavior. This
> >> means that the semantics of some extant applications will change.
Bruce Momjian writes:
> On Mon, Apr 12, 2021 at 03:09:48PM -0700, Bryn Llewellyn wrote:
>> After all, you've bitten the bullet now and changed the behavior. This means
>> that the semantics of some extant applications will change. So... in for a
>> penny, in for a pound?
> The docs now say:
>
On Mon, Apr 12, 2021 at 03:09:48PM -0700, Bryn Llewellyn wrote:
> I showed you all this example a long time ago:
>
> select (
> '
> 3.853467 years
> '::interval
> )::text as i;
>
> This behavior is the same in the env. of Bruce’s patch as in unpatched PG
> 13.2. This is the
br...@momjian.us wrote:
>
> z...@yugabyte.com wrote:
>> Among previous examples given by Bryn, the following produces correct result
>> based on Bruce's patch.
>>
>> # select interval '-1.7 years 29.4 months';
>> interval
>>
>> 9 mons 12 days
>
> Yes, that changed is
On Sun, Apr 11, 2021 at 07:33:34PM -0700, Zhihong Yu wrote:
> Among previous examples given by Bryn, the following produces correct result
> based on Bruce's patch.
>
> # select interval '-1.7 years 29.4 months';
> interval
>
> 9 mons 12 days
Yes, that changed is caused by
On Sun, Apr 11, 2021 at 4:33 PM Zhihong Yu wrote:
>
>
> On Sun, Apr 11, 2021 at 12:57 PM Zhihong Yu wrote:
>
>>
>>
>> On Thu, Apr 8, 2021 at 10:24 AM Bruce Momjian wrote:
>>
>>> On Mon, Apr 5, 2021 at 02:01:58PM -0400, Bruce Momjian wrote:
>>> > On Mon, Apr 5, 2021 at 11:33:10AM -0500,
On Sun, Apr 11, 2021 at 12:57 PM Zhihong Yu wrote:
>
>
> On Thu, Apr 8, 2021 at 10:24 AM Bruce Momjian wrote:
>
>> On Mon, Apr 5, 2021 at 02:01:58PM -0400, Bruce Momjian wrote:
>> > On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
>> > Well, bug or not, we are not going to change
On Thu, Apr 8, 2021 at 10:24 AM Bruce Momjian wrote:
> On Mon, Apr 5, 2021 at 02:01:58PM -0400, Bruce Momjian wrote:
> > On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
> > Well, bug or not, we are not going to change back branches for this, and
> > if you want a larger
> On 08-Apr-2021, at 10:24, Bruce Momjian wrote:
>
> On Mon, Apr 5, 2021 at 02:01:58PM -0400, Bruce Momjian wrote:
>> On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
>> Well, bug or not, we are not going to change back branches for this, and
>> if you want a larger discussion, it
On Mon, Apr 5, 2021 at 02:01:58PM -0400, Bruce Momjian wrote:
> On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
> Well, bug or not, we are not going to change back branches for this, and
> if you want a larger discussion, it will have to wait for PG 15.
>
> > >
> On 05-Apr-2021, at 13:35, Bruce Momjian wrote:
>
> On Mon, Apr 5, 2021 at 01:06:36PM -0700, Bryn Llewellyn wrote:
>>> On 05-Apr-2021, at 11:37, Bruce Momjian wrote On:
>>> Mon, Apr 5, 2021 at 01:15:22PM -0500, Justin Pryzby wrote :
>>
>> It seems to me that this whole business is an
On Mon, Apr 5, 2021 at 01:06:36PM -0700, Bryn Llewellyn wrote:
> > On 05-Apr-2021, at 11:37, Bruce Momjian wrote On:
> > Mon, Apr 5, 2021 at 01:15:22PM -0500, Justin Pryzby wrote :
>
> It seems to me that this whole business is an irrevocable mess. The
> original design could have
On Mon, Apr 5, 2021 at 01:15:22PM -0500, Justin Pryzby wrote:
> On Mon, Apr 05, 2021 at 02:01:58PM -0400, Bruce Momjian wrote:
> > On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
> > > > https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-INTERVAL-INPUT
> > > >
On Mon, Apr 05, 2021 at 02:01:58PM -0400, Bruce Momjian wrote:
> On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
> > > https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-INTERVAL-INPUT
> > > « …field values can have fractional parts; for example '1.5 week' or
>
On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
> On Fri, Apr 02, 2021 at 10:21:26PM -0400, Bruce Momjian wrote:
> > I wish I could figure out how to improve it any futher. What is odd is
> > that I have never seen this reported as a problem before. I plan to
> > apply this early
On Fri, Apr 02, 2021 at 10:21:26PM -0400, Bruce Momjian wrote:
> I wish I could figure out how to improve it any futher. What is odd is
> that I have never seen this reported as a problem before. I plan to
> apply this early next week for PG 14.
On Fri, Apr 02, 2021 at 01:05:42PM -0700, Bryn
On Fri, Apr 2, 2021 at 07:53:35PM -0700, Zhihong Yu wrote:
> Bruce:
> In src/interfaces/ecpg/pgtypeslib/interval.c, how about the following places ?
>
> Around line 158:
> case 'Y':
> tm->tm_year += val;
> tm->tm_mon += (fval *
Bruce:
In src/interfaces/ecpg/pgtypeslib/interval.c, how about the following
places ?
Around line 158:
case 'Y':
tm->tm_year += val;
tm->tm_mon += (fval * MONTHS_PER_YEAR);
Around line 194:
tm->tm_year += val;
On Fri, Apr 2, 2021 at 07:06:08PM -0700, Zhihong Yu wrote:
> Hi,
> The mix of interval and comparison with float is not easy to interpret. See
> the
> following (I got 0.0833 since the result for interval '0.3 years' + interval
> '0.4 years' - ... query was 1 month and 1/12 ~= 0.0833).
>
>
On Fri, Apr 2, 2021 at 06:11:08PM -0700, Zhihong Yu wrote:
> Hi,
> I got a local build with second patch where:
>
> yugabyte=# SELECT interval '0.3 years' + interval '0.4 years' -
> interval '0.7 years';
> ?column?
> --
> 1 mon
>
> I think the outcome is a bit
Hi,
The mix of interval and comparison with float is not easy to interpret. See
the following (I got 0.0833 since the result for interval '0.3 years' +
interval '0.4 years' - ... query was 1 month and 1/12 ~= 0.0833).
yugabyte=# select 0.3 * '1 year'::interval + 0.4 * '1 year'::interval - 0.7
*
On Fri, 2 Apr 2021 at 21:08, Zhihong Yu wrote:
> Hi,
> I got a local build with second patch where:
>
> yugabyte=# SELECT interval '0.3 years' + interval '0.4 years' -
> interval '0.7 years';
> ?column?
> --
> 1 mon
>
> I think the outcome is a bit unintuitive (I would
Hi,
I got a local build with second patch where:
yugabyte=# SELECT interval '0.3 years' + interval '0.4 years' -
interval '0.7 years';
?column?
--
1 mon
I think the outcome is a bit unintuitive (I would expect result close to 0).
Cheers
On Fri, Apr 2, 2021 at 5:07 PM
On Fri, Apr 2, 2021 at 05:50:59PM -0700, Bryn Llewellyn wrote:
> are the user’s parameterization. All are real numbers. Because non-integral
> values for years, months, days, hours, and minutes are allowed when you
> specify
> a value using the ::interval typecast, my reference doc must state
br...@momjian.us wrote:
> I have just posted a new version of the patch which I think covers all the
> right areas.
I found the relevant email from you to pgsql-hackers here:
https://www.postgresql.org/message-id/20210402234732.GA29125%40momjian.us
You said:
> I have modified the patch to
On Fri, Apr 2, 2021 at 07:47:32PM -0400, Bruce Momjian wrote:
> I have modified the patch to prevent partial months from creating
> partial hours/minutes/seconds, so the output is now at least consistent
> based on the three units:
>
> SELECT ('6.54321 years'::interval)::text as i;
>
Hi,
bq. My new code returns 0.2 months for this, not zero
Can you clarify (the output below that was 2 mons, not 0.2) ?
Thanks
On Fri, Apr 2, 2021 at 4:58 PM Bruce Momjian wrote:
> On Fri, Apr 2, 2021 at 02:00:03PM -0700, John W Higgins wrote:
> > On Fri, Apr 2, 2021 at 11:05 AM Bruce
On Fri, Apr 2, 2021 at 02:00:03PM -0700, John W Higgins wrote:
> On Fri, Apr 2, 2021 at 11:05 AM Bruce Momjian wrote:
> While maybe there is an argument to fixing the negative/positive rounding
> issue
> - there is no way this gets solved without breaking the current implementation
>
> select
On Fri, Apr 2, 2021 at 01:27:33PM -0700, Zhihong Yu wrote:
> Bruce:
> Thanks for tackling this issue.
>
> The patch looks good to me.
> When you have time, can you include the places which were not covered by the
> current diff ?
I have just posted a new version of the patch which I think
On Fri, Apr 2, 2021 at 01:05:42PM -0700, Bryn Llewellyn wrote:
> I should come clean about the larger context. I work for Yugabyte, Inc. We
> have
> a distributed SQL database that uses the Version 11.2 PostgreSQL C code for
> SQL
> processing “as is”.
>
> https://blog.yugabyte.com/
>
On Fri, Apr 2, 2021 at 11:05 AM Bruce Momjian wrote:
> On Thu, Apr 1, 2021 at 09:46:58PM -0700, Bryn Llewellyn wrote:
> > Or am I misunderstanding something?
> >
> > Try this. The result of each “select” is shown as the trailing comment
> on the
> > same line. I added whitespace by hand to line
Bruce:
Thanks for tackling this issue.
The patch looks good to me.
When you have time, can you include the places which were not covered by
the current diff ?
Cheers
On Fri, Apr 2, 2021 at 11:06 AM Bruce Momjian wrote:
> On Thu, Apr 1, 2021 at 09:46:58PM -0700, Bryn Llewellyn wrote:
> > Or
On Thu, Apr 1, 2021 at 09:46:58PM -0700, Bryn Llewellyn wrote:
> Or am I misunderstanding something?
>
> Try this. The result of each “select” is shown as the trailing comment on the
> same line. I added whitespace by hand to line up the fields.
>
> select interval '-1.7 years';
93 matches
Mail list logo
