Re: use-regular-expressions-to-simplify-less_greater-and-not_equals.patch

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 孙诗浩(思才) <sunshihao(dot)ssh(at)alibaba-inc(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, 范孝剑(康贤) <funnyxj(dot)fxj(at)alibaba-inc(dot)com>
Subject: Re: use-regular-expressions-to-simplify-less_greater-and-not_equals.patch
Date: 2021-08-11 04:29:49
Message-ID: CAKFQuwZDKn4R02x2-C_DPX4+qOb8hShN8YKvt5ondKTVuCdYRQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 10, 2021 at 8:36 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "=?UTF-8?B?5a2Z6K+X5rWpKOaAneaJjSk=?=" <sunshihao(dot)ssh(at)alibaba-inc(dot)com>
> writes:
> > we can use regular expressions (<>|!=) to cover "<>" and "!=".
> There is no
> > need to have two definitions less_greater and not_equals, because it
> will confuse developer.
> > So, we can use only not_equals to cover this operator set.
>
> I do not find this an improvement.

Agreed, though mostly on a separation of responsibilities principle.
Labelling the distinctive tokens and then assigning them meaning are two
different things.

Yeah, it's a bit shorter, but it's
> less clear;

not least because the comment explaining the <>-means-!=
> behavior is no longer anywhere near the code that implements that
> behavior.

The patch should just remove the comment for not_equals as well: if both
tokens are given the same name they would have to be treated identically.
The fact they have the same name is clearer in that the equivalency
knowledge is immediate and impossible to miss (if one doesn't go and check
how "less_greater" and "not_equal" are interpreted.)

It would also get in the way if we ever had reason to treat <>
> and != as something other than exact equivalents.
>
>
This is unconvincing both on the odds of being able to treat them
differently and the fact that the degree of effort to overcome this
obstacle seems minimal - about the same amount as reverting this patch, not
accounting for the coding of the new behavior.

In short, for me, is a principled separation of concerns worth the slight
loss is clarity? I'll stick to my status quo choice, but not strongly.
Some more context as to exactly what kind of confusion this setup is
causing could help tip the scale.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2021-08-11 04:51:02 Allow parallel DISTINCT
Previous Message Dilip Kumar 2021-08-11 03:47:16 Re: Support reset of Shared objects statistics in "pg_stat_reset" function