I wrote:
> I've marked this RFC, and will push tomorrow unless somebody wants
> to object to the loss of backwards compatibility.
And done. I noticed in some final testing that it's possible to
make this code take a long time by forcing it to backtrack a lot:
regression=# SELECT (('1' || repeat(
Nikita Glukhov writes:
> I think now it looks as simple as the whole algorithm is.
Yeah, I think we've gotten checkCond to the point of "there's no
longer anything to take away".
I've marked this RFC, and will push tomorrow unless somebody wants
to object to the loss of backwards compatibility.
On 31.03.2020 1:35, Tom Lane wrote:
Nikita Glukhov writes:
And we even can simply transform this tail call into a loop:
-if (tlen > 0 && qlen > 0)
+while (tlen > 0 && qlen > 0)
Yeah, the same occurred to me ... and then we can drop the other loop too.
I think now it looks as simple as the
Nikita Glukhov writes:
> And we even can simply transform this tail call into a loop:
> -if (tlen > 0 && qlen > 0)
> +while (tlen > 0 && qlen > 0)
Yeah, the same occurred to me ... and then we can drop the other loop too.
I've got it down to this now:
/*
* Try to match an lquery (of qlen items
On 31.03.2020 1:12, Tom Lane wrote:
I wrote:
I dunno, that doesn't really seem clearer to me (although some of it
might be that you expended no effort on making the comments match
the new code logic).
... although looking closer, this formulation does have one very nice
advantage: for the typi
I wrote:
> I dunno, that doesn't really seem clearer to me (although some of it
> might be that you expended no effort on making the comments match
> the new code logic).
... although looking closer, this formulation does have one very nice
advantage: for the typical non-star case with high = low
Nikita Glukhov writes:
> On 30.03.2020 21:00, Tom Lane wrote:
>> Hence, new patch versions that do it like that. (0002 is unchanged.)
> I tried to simplify a bit loops in checkCond() by merging two of them into
> one with an explicit exit condition. Also I added return statement after
> this lo
On 30.03.2020 21:00, Tom Lane wrote:
Hence, new patch versions that do it like that. (0002 is unchanged.)
I tried to simplify a bit loops in checkCond() by merging two of them into
one with an explicit exit condition. Also I added return statement after
this loop, so it's now clear that we c
I wrote:
> Hence, attached are two revised patches that attack the problem
> this way. The first one is somewhat unrelated to the original
> point --- it's trying to clean up the error messages in ltree_in
> and lquery_in so that they are more consistent and agree with
> the terminology used in th
I wrote:
> My main complaint about it remains the same, that it changes a
> disturbingly large number of existing regression-test results,
> suggesting that there's not a meeting of the minds about what
> this logic is supposed to do. Maybe it's okay or maybe it's
> not, but who's going to decide?
Nikita Glukhov writes:
> On 24.01.2020 21:29, Tomas Vondra wrote:
>> Unfortunately, the current code is somewhat undercommented :-(
> The main problem is that no one really understands how it works now.
Indeed. I was disturbed to realize that lquery_op.c, despite being
far from trivial code, co
On 24.01.2020 21:29, Tomas Vondra wrote:
Hi Nikita,
This patch seems inactive / stuck in "waiting on author" since November.
It's marked as bugfix, so it'd be good to get it committed instead of
just punting it to the next CF.
I did a quick review, and I came mostly with the same two complaint
Hi,
I've moved this patch to the next CF - it's still in WoA state, but it's
supposedly a bugfix so I've decided not to return it with feedback.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi Nikita,
This patch seems inactive / stuck in "waiting on author" since November.
It's marked as bugfix, so it'd be good to get it committed instead of
just punting it to the next CF.
I did a quick review, and I came mostly with the same two complaints as
Alexander ...
On Wed, Jul 17, 2019 at
On Thu, Sep 05, 2019 at 04:50:58PM -0400, Alvaro Herrera from 2ndQuadrant wrote:
> Hi Oleg, Teodor. Did you find time to refresh your memory on these things?
> It would be good to have these bugfixes sorted out.
Two months later. Now would be a good time as well! Alexander, you
have also looked
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, failed
This is my first PostgreSQL commitfest and review, guidance welco
On 2019-Jul-09, Oleg Bartunov wrote:
> On Mon, Jul 8, 2019 at 7:22 AM Thomas Munro wrote:
> >
> > On Sun, Apr 7, 2019 at 3:46 AM Tom Lane wrote:
> > > In short, I'm wondering if we should treat this as a documentation
> > > bug not a code bug. But to do that, we'd need a more accurate
> > > de
On Tue, Jul 16, 2019 at 8:52 PM Nikita Glukhov
wrote:
>
> On 09.07.2019 17:57, Oleg Bartunov wrote:
>
> On Mon, Jul 8, 2019 at 7:22 AM Thomas Munro
> wrote:
>
> On Sun, Apr 7, 2019 at 3:46 AM Tom Lane
> wrote:
>
> =?UTF-8?Q?Filip_Rembia=C5=82kowski?=
> writes:
>
> Here is my attempt to f
Please create separate commitfest entry.
Hi Nikita,
On Tue, Jul 16, 2019 at 6:52 PM Nikita Glukhov wrote:
> I looked at "ltree syntax improvement" patch and found two more very
> old bugs in ltree/lquery (fixes are attached):
Thank you for the fixes. I've couple notes on them.
0001-Fix-max-size-checking-for-ltree-and-lquery.patch
+#
On 09.07.2019 17:57, Oleg Bartunov wrote:
On Mon, Jul 8, 2019 at 7:22 AM Thomas Munro wrote:
On Sun, Apr 7, 2019 at 3:46 AM Tom Lane wrote:
=?UTF-8?Q?Filip_Rembia=C5=82kowski?= writes:
Here is my attempt to fix a 12-years old ltree bug (which is a todo item).
I see it's not backward-compat
On Mon, Jul 8, 2019 at 7:22 AM Thomas Munro wrote:
>
> On Sun, Apr 7, 2019 at 3:46 AM Tom Lane wrote:
> > =?UTF-8?Q?Filip_Rembia=C5=82kowski?= writes:
> > > Here is my attempt to fix a 12-years old ltree bug (which is a todo item).
> > > I see it's not backward-compatible, but in my understandin
On Sun, Apr 7, 2019 at 3:46 AM Tom Lane wrote:
> =?UTF-8?Q?Filip_Rembia=C5=82kowski?= writes:
> > Here is my attempt to fix a 12-years old ltree bug (which is a todo item).
> > I see it's not backward-compatible, but in my understanding that's
> > what is documented. Previous behavior was inconsi
=?UTF-8?Q?Filip_Rembia=C5=82kowski?= writes:
> Here is my attempt to fix a 12-years old ltree bug (which is a todo item).
> I see it's not backward-compatible, but in my understanding that's
> what is documented. Previous behavior was inconsistent with
> documentation (where single asterisk should
24 matches
Mail list logo
