On Thu, 12 Jan 2023 at 11:59, Gurjeet Singh <gurj...@singh.im> wrote: > > On Thu, Jan 12, 2023 at 1:49 AM Matthias van de Meent > <boekewurm+postg...@gmail.com> wrote: > > > > On Thu, 12 Jan 2023 at 10:16, Gurjeet Singh <gurj...@singh.im> 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.
I see. Wouldn't it be better then to instead make it possible for the planner to detect the use of the functions used in operators and treat them as aliases of the operator? Or am I missing something w.r.t. differences between operator and function invocation? E.g. indexes on `int8pl(my_bigint, 1)` does not match queries for `my_bigint + 1` (and vice versa), while they should be able to support that, as OPERATOR(pg_catalog.+(int8, int8)) 's function is int8pl. Kind regards, Matthias van de Meent