| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
| Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, "L(dot) pgsql-hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Subject: | Re: Fix unqualified catalog references in psql describe queries |
| Date: | 2026-06-15 17:22:56 |
| Message-ID: | 239323.1781544176@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre(at)kurilemu(dot)de> writes:
> My proposal would be that all operators, both system-defined as well as
> user-defined, live in a single namespace -- not that we forbid them from
> being created.
Exactly how does that improve anyone's life? It will certainly not
improve query security, rather the reverse. You could no longer put
less-trusted stuff into a schema that's not in your search_path.
Yes, it would stop people from creating operators that are exact
duplicates of system operators, but those are not the problem:
user-defined operators like that are already masked by the lookup
rules, assuming that pg_catalog is searched first as is the normal
case. The thing that is dangerous is a user-defined operator that
is made to capture cases that lack an exact system-operator match
(say, varchar = text). AFAICS your proposal puts those on exactly the
same footing as system-defined operators, and there is no recourse.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-06-15 17:50:46 | use of SPI by postgresImportForeignStatistics |
| Previous Message | Nathan Bossart | 2026-06-15 17:20:31 | Re: fix prev link in docs |