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

  1. psql: Add some missing schema qualifications in describe.c

  2. SQL Property Graph Queries (SQL/PGQ)

  3. CREATE SUBSCRIPTION ... SERVER.