Re: Fixes for missing schema qualifications

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, Noah Misch <noah(at)leadboat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fixes for missing schema qualifications
Date: 2018-03-14 01:54:39
Message-ID: 20180314015439.GG1150@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 13, 2018 at 05:19:50PM -0700, David G. Johnston wrote:
> On Tue, Mar 13, 2018 at 5:11 PM, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> wrote:
>> select pg_catalog.count(*) from pg_catalog.pg_namespace where
>> pg_catalog.nameeq(nspname, '%s');
>>
>>
> ​I'd rather write that:
>
> select [...] where nspname operator(pg_catalog.=) '%s'​
>
> Introducing undocumented implementation functions to these queries is
> undesirable; and besides, indexing and equivalence relies on operators and
> not the underlying functions so there would be some risk of performance
> issues if the functions were used directly.

Using directly the function calls calls under the wood of what an
operator does is a potential solution, though I would discard it as it
becomes harder for the reader to undertand that this is an operator.
Things become even more confusing when dealing with input parameters of
different types for simple maths like addition, multiplication or
division using several kinds of integers, leading to more complications
in maintaining this code in the future. And the operator is careful
about doing proper casting itself.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2018-03-14 01:56:30 Re: neqjoinsel versus "refresh materialized view concurrently"
Previous Message Michael Paquier 2018-03-14 01:50:38 Re: Fixes for missing schema qualifications