At Mon, 1 Aug 2022 13:29:09 -0700, Jacob Champion
wrote in
> As discussed in [1], we're taking this opportunity to return some
> patchsets that don't appear to be getting enough reviewer interest.
Oh, sorry. I missed that thread. Thank you for kindly noticing that.
> This is not a rejection, s
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
At Wed, 15 Dec 2021 16:20:55 +0900 (JST), Kyotaro Horiguchi
wrote in
> adjusted so that it treats null as false. On the way doing this, the
> bug #17334 [2] and another bug raised earlier [3] are naturally fixed.
That being said, even if this patch were committed to the master
branch, we won't
On 12/21/20 3:30 AM, Kyotaro Horiguchi wrote:
At Tue, 01 Dec 2020 10:03:42 -0500, Tom Lane wrote in
I think it should be "needs review" now.
Conflicted with some commit(s) uncertain to me. Rebased.
Tom, Georgios, thoughts on the new patch?
Regards,
--
-David
da...@pgmasters.net
At Tue, 01 Dec 2020 10:03:42 -0500, Tom Lane wrote in
> I think it should be "needs review" now.
Conflicted with some commit(s) uncertain to me. Rebased.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 26d9edeccf3f3111a7e0ff049aa6e3ba3746dce9 Mon Sep 17 00:00:00 2001
From:
Anastasia Lubennikova writes:
> The commitfest is closed now and this entry is "Waiting on author".
> As far as I see, part of the fixes is already committed. Is there
> anything left to work on or this patch needs review/ ready for committer
> now?
I think it should be "needs review" now.
On 25.11.2020 11:14, Kyotaro Horiguchi wrote:
At Wed, 25 Nov 2020 11:39:39 +0900 (JST), Kyotaro Horiguchi
wrote in
So that line of thought prompts me to tread *very* carefully when
trying to dodge NaN results. We need to be certain that we
introduce only logically-defensible special cases. S
At Wed, 25 Nov 2020 11:39:39 +0900 (JST), Kyotaro Horiguchi
wrote in
> > So that line of thought prompts me to tread *very* carefully when
> > trying to dodge NaN results. We need to be certain that we
> > introduce only logically-defensible special cases. Something like
> > float8_coef_mul()
(My mailer seems to have recovered from unresponsiveness.)
At Tue, 24 Nov 2020 12:29:41 -0500, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > At Fri, 20 Nov 2020 15:57:46 -0500, Tom Lane wrote in
> >> I don't much like anything about float8_coef_mul().
>
> > I have the same feeling on the
Kyotaro Horiguchi writes:
> At Fri, 20 Nov 2020 15:57:46 -0500, Tom Lane wrote in
>> I don't much like anything about float8_coef_mul().
> I have the same feeling on the function, but I concluded that
> coefficients and coordinates should be regarded as different things in
> the practical stand
At Fri, 20 Nov 2020 15:57:46 -0500, Tom Lane wrote in
> I spent some more time looking at this patch.
>
> Some experimentation shows that the changes around bounding box
> calculation (ie float8_min_nan() and its call sites) seem to be
> completely pointless: removing them doesn't change any of
At Sat, 21 Nov 2020 17:33:53 -0500, Tom Lane wrote in
> I went ahead and pushed 0001 and 0003 (the latter in two parts), since
> they didn't seem particularly controversial to me. Just to keep the
> cfbot from whining, here's a rebased version of 0002.
I didn't noticed that inf == inf sould be
I went ahead and pushed 0001 and 0003 (the latter in two parts), since
they didn't seem particularly controversial to me. Just to keep the
cfbot from whining, here's a rebased version of 0002.
regards, tom lane
diff --git a/src/backend/utils/adt/geo_ops.c b/src/backend/ut
Further to this ...
I realized after looking at things some more that one of
line_closept_point's issues is really a bug in line_construct:
it fails to draw a horizontal line through a point with x = Inf,
though surely that's not particularly ill-defined. The reason
is that somebody thought they
I spent some more time looking at this patch.
Some experimentation shows that the changes around bounding box
calculation (ie float8_min_nan() and its call sites) seem to be
completely pointless: removing them doesn't change any of the regression
results. Nor does using float8_min_nan() in the ot
Kyotaro Horiguchi writes:
> At Tue, 10 Nov 2020 14:30:08 -0500, Tom Lane wrote in
>> For instance, {1,-1,0} is the line "x = y". We could argue about
>> whether it'd be sensible to return zero for the distance between that
>> and the point (inf,inf), but surely any point with one inf and one
>>
At Fri, 13 Nov 2020 15:35:58 +0900 (JST), Kyotaro Horiguchi
wrote in
> Thank you for the review, Georgios and Tom.
>
> At Tue, 10 Nov 2020 14:30:08 -0500, Tom Lane wrote in
> > I spent some time looking this over, and have a few thoughts:
> >
> > 1. I think it's useful to split the test chan
Thank you for the review, Georgios and Tom.
At Tue, 10 Nov 2020 14:30:08 -0500, Tom Lane wrote in
> I spent some time looking this over, and have a few thoughts:
>
> 1. I think it's useful to split the test changes into two patches,
> as I've done below: first, just add the additional row in po
I spent some time looking this over, and have a few thoughts:
1. I think it's useful to split the test changes into two patches,
as I've done below: first, just add the additional row in point_tbl
and let the fallout from that happen, and then in the second patch
make the code changes. This way,
At Mon, 02 Nov 2020 14:43:32 +, Georgios Kokolatos
wrote in
> Hi,
>
> apologies for the very, very late reply to your fixes.
>
> You have answered/addressed all my questions concerns. The added documentation
> reads well, at least to a non native English speaker.
>
> The patch still appli
Hi,
apologies for the very, very late reply to your fixes.
You have answered/addressed all my questions concerns. The added documentation
reads well, at least to a non native English speaker.
The patch still applies and as far as I can see the tests are passing.
It gets my :+1: and I am changin
Hello, Georgios.
At Mon, 07 Sep 2020 12:46:50 +, gkokola...@pm.me wrote in
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 27 August 2020 14:24, Kyotaro Horiguchi
> wrote:
>
> > At Wed, 26 Aug 2020 08:18:49 -0400, Tom Lane t...@sss.pgh.pa.us wrote in
> >
> > > Kyotaro Horiguchi horikyota
‐‐‐ Original Message ‐‐‐
On Thursday, 27 August 2020 14:24, Kyotaro Horiguchi
wrote:
> At Wed, 26 Aug 2020 08:18:49 -0400, Tom Lane t...@sss.pgh.pa.us wrote in
>
> > Kyotaro Horiguchi horikyota@gmail.com writes:
> >
> > > At Tue, 25 Aug 2020 19:03:50 -0400, Bruce Momjian br...@m
At Wed, 26 Aug 2020 08:18:49 -0400, Tom Lane wrote in
> Kyotaro Horiguchi writes:
> > At Tue, 25 Aug 2020 19:03:50 -0400, Bruce Momjian wrote
> > in
> >> I can confirm that this two-month old email report still produces
> >> different results with indexes on/off in git master, which I don't t
Kyotaro Horiguchi writes:
> At Tue, 25 Aug 2020 19:03:50 -0400, Bruce Momjian wrote in
>> I can confirm that this two-month old email report still produces
>> different results with indexes on/off in git master, which I don't think
>> is ever correct behavior.
> I agree to that the behavior is
At Tue, 25 Aug 2020 19:03:50 -0400, Bruce Momjian wrote in
>
> I can confirm that this two-month old email report still produces
> different results with indexes on/off in git master, which I don't think
> is ever correct behavior.
I agree to that the behavior is broken.
> ---
I can confirm that this two-month old email report still produces
different results with indexes on/off in git master, which I don't think
is ever correct behavior.
---
On Wed, Jun 24, 2020 at 03:11:03PM -0700, Jesse Zhang
Hi hackers,
While working with Chris Hajas on merging Postgres 12 with Greenplum
Database we stumbled upon the following strange behavior in the geometry
type polygon:
-- >8
CREATE TEMP TABLE foo (p point);
CREATE INDEX ON foo USING gist(p);
INSERT INTO foo VALUES ('0,0'), ('1,1'),
28 matches
Mail list logo
