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: | Whole Thread | Raw Message | 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
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 |