Re: Fix unqualified catalog references in psql describe queries
Álvaro Herrera <alvherre@kurilemu.de>
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Michael Paquier <michael@paquier.xyz>, Chao Li <li.evan.chao@gmail.com>, "L. pgsql-hackers" <pgsql-hackers@lists.postgresql.org>,
Fujii Masao <masao.fujii@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, Jeff Davis <pgsql@j-davis.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
Amit Kapila <amit.kapila16@gmail.com>
Date: 2026-06-15T17:08:22Z
Lists: pgsql-hackers
On 2026-Jun-10, Tom Lane wrote: > =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de> writes: > > I think we should just ditch the idea that operators live in schemas. > > How would you do that without removing user-defined operators > altogether? (And thereby breaking most extensions.) 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. I expect extensions mostly create operators for the data types they themselves define, not for existing system datatypes. I think the idea of public.=(int,int) being different from pg_catalog.=(int,int) is just too dangerous and trips people up without giving much valuable functionality. If the extension offers =(complex,complex) then that's fine: we would still have overloading per the type system. I may be missing something though. Care to point out what it is? -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "El que vive para el futuro es un iluso, y el que vive para el pasado, un imbécil" (Luis Adler, "Los tripulantes de la noche")
Commits
-
psql: Add some missing schema qualifications in describe.c
- bf5206f00773 19 (unreleased) landed
-
SQL Property Graph Queries (SQL/PGQ)
- 2f094e7ac691 19 (unreleased) cited
-
CREATE SUBSCRIPTION ... SERVER.
- 8185bb534763 19 (unreleased) cited