| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fixes for missing schema qualifications |
| Date: | 2018-03-14 00:19:50 |
| Message-ID: | CAKFQuwYGXhD7ngZ-xJHg+GR8Avn5nPhcv7g_yWxD8fLH+DqNhw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 nspname = '%s'",
> >>
> >> This qualifies some functions, but it leaves plenty of unqualified
> operators.
>
> Oops. I meant:
>
> 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.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2018-03-14 00:20:15 | Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath |
| Previous Message | Tatsuo Ishii | 2018-03-14 00:11:53 | Re: Fixes for missing schema qualifications |