public inbox for [email protected]  

help / color / mirror / Atom feed

From: Gurjeet Singh <[email protected]>
To: Matthias van de Meent <[email protected]>
Cc: Postgres Hackers <[email protected]>
Subject: Re: Named Operators
Date: Thu, 12 Jan 2023 02:59:04 -0800
Message-ID: <CABwTF4Uh3FUK6_9mj_aszciLt-CU0eYKiCdaL1nXShjxaHhbqQ@mail.gmail.com> (raw)
In-Reply-To: <CAEze2WjeYjcf-bm_4gggK7PQ+9fQQ6=hzGeYxTRY9r+D-BPt8g@mail.gmail.com>
References: <CABwTF4VVuacLV+coERacdDxUXg5tDMHZxvgH5+ek0UZvoq386g@mail.gmail.com>
	<CAEze2WjeYjcf-bm_4gggK7PQ+9fQQ6=hzGeYxTRY9r+D-BPt8g@mail.gmail.com>

On Thu, Jan 12, 2023 at 1:49 AM Matthias van de Meent
<[email protected]> wrote:
>
> On Thu, 12 Jan 2023 at 10:16, Gurjeet Singh <[email protected]> wrote:
> >
> > Technically correct name of this feature would be Readable Names for
> > Operators, or Pronounceable Names for Operators. But I'd like to call
> > it Named Operators.
> >
> > With this patch in place, the users can name the operators as
> > :some_pronounceable_name: instead of having to choose from the special
> > characters like #^&@.
> > [...]
> >     I think Named Operators will significantly improve the readability
> > of queries.
>
> Couldn't the user better opt to call the functions that implement the
> operator directly if they want more legible operations? So, from your
> example, `SELECT box_add(a, b)` instead of `SELECT a :add_point: b`?

Matter of taste, I guess. But more importantly, defining an operator
gives you many additional features that the planner can use to
optimize your query differently, which it can't do with functions. See
the COMMUTATOR, HASHES, etc. clause in the CREATE OPERATOR command.

https://www.postgresql.org/docs/current/sql-createoperator.html

This proposal is primarily a replacement for the myriad of
hard-to-pronounce operators that users have to memorize. For example,
it'd be nice to have readable names for the PostGIS operators.

https://postgis.net/docs/reference.html#Operators

For someone who's reading/troubleshooting a PostGIS query, when they
encounter operator <<| — in the query for the first time, they'd have
to open up the docs. But if the query used the :strictly_below:
operator, there's no need to switch to docs and lose context.

> I'm -1 on the chosen syntax; :name: shadows common variable
> substitution patterns including those of psql.

Ah, thanks for reminding! Early on when I hadn't written code yet, I
remember discarding colon : as a delimiter choice, precisely because
it is used for using variables in psql, and perhaps in some drivers,
as well. But in the rush of implementing and wrangling code, I forgot
about that argument altogether.

I'll consider using one of the other special characters. Do you have
any suggestions?


Best regards,
Gurjeet
http://Gurje.et

view thread (14+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Named Operators
  In-Reply-To: <CABwTF4Uh3FUK6_9mj_aszciLt-CU0eYKiCdaL1nXShjxaHhbqQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox