Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vvyaE-00DQtp-33 for pgsql-docs@arkaria.postgresql.org; Fri, 27 Feb 2026 14:12:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vvyaC-003oyQ-2H for pgsql-docs@arkaria.postgresql.org; Fri, 27 Feb 2026 14:12:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vvyaC-003oyA-1Q for pgsql-docs@lists.postgresql.org; Fri, 27 Feb 2026 14:12:44 +0000 Received: from mail-oo1-xc32.google.com ([2607:f8b0:4864:20::c32]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vvya9-00000001a37-2PgQ for pgsql-docs@lists.postgresql.org; Fri, 27 Feb 2026 14:12:44 +0000 Received: by mail-oo1-xc32.google.com with SMTP id 006d021491bc7-662f5c5507cso1763350eaf.3 for ; Fri, 27 Feb 2026 06:12:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772201560; cv=none; d=google.com; s=arc-20240605; b=NoI5nvkfcaFmmXno8SVN+3tfdUeXP5xN8ZCnWmWesOCzUWnd7l9ten4MFxEfuq1oFK 2dangGMguig7ukbuosgajmlHSRp22iRW/WuCsLq5mtunrgtjjSGDrUHawItwwK/MergN 3aNBprS631kkMZ+sM0UzOehBneTWN6afW3HEt0f98sUr5A6+2D1/cWbQ24o6x7rQKBtg WjrDwnerit4GVq7Y7jFoGpSkju0eD0DxEBup9STQFZDp9e4257T3KE3f5dfvlOfgBgaB kgP+hsgzPeilunXbxUfaIg9amhogPLHa5SVFhFWHJDop1Ju1vqAhLDoU0J2Sr64sKFlh +ISg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature; bh=P6Bb/FVBv1Rx4+ZdOWweE4OtAajdLopxiqBa2mqR5oo=; fh=SVBMUearq+HnhPgppy9EQX4/o0WjEhQM1n1974lBHYQ=; b=XMIuqz/QncI1tBwPznOomakGRjQmle9wL9SmuNIJlqZAqgGun0S3svz6oPAqlh5xep SJ8Xrkll94mfEl0dqFtCSWmpRH1AANpGn5f4slqOQ/A+X9jZB4dy/tM6s24N+yPlt8gV 3YGSz+5ss/Q9OuAOPlu3MA1FjG9fipefm6a6VOADyaWFxTVLSzQpT6PKxNPg9H2EzYEv uTxBzoLvBB3HV6b4tX9BzOfFeWijbC/CXbwFoKXk1QPJH4CId+6QUOLX54FPGCRxri8O /f+ayx7KDCwGw2aV58opcVQhAdsPPIc2A6mfrYAyi45FUy/IMtjlqmq4TzB2OjKAyinT 1Xrg==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772201560; x=1772806360; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=P6Bb/FVBv1Rx4+ZdOWweE4OtAajdLopxiqBa2mqR5oo=; b=EzCqH1DVirZjOOBDpXq2Fw9KZCojx1WMCicuhpmW5iyiJyS4h4qdbQixuAd6iWjE1y JLlzwb3WOf8L011S8l+R9w/oGlR363N05FUJ+Jc0g1BLGMdwXSdWf48C3uvnBGtGBYOa gu+Oq+ShG/pl7eATOYRzFwQ7s8WPyVVB3pTjuqRPQB9PI31S4HJwn+n2LPcMuGpawo8k jvy+3he9atQtu1gcojAQNZrPZHpzbqCAmK2YP/FT8pVD+vlCRfXXmkbVfUUHMlCVtRwe J8qxmx080AyljMDZ7Oni8xCM93PRTxfQN7wMtopxMg6geTQhkOIaIteMK3VoS/29p9jI Y6Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772201560; x=1772806360; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=P6Bb/FVBv1Rx4+ZdOWweE4OtAajdLopxiqBa2mqR5oo=; b=o3ck6ylg67q1UMbTY8tXJBIllDxEBGChHvaEXiAlOX+Y3TssgVUPSA7QvVaEit3jjU iW99WV1zETRaZntHccHEwet1Cr9u3XKyhyRLvIdbkfObvkLod8yvW26Y0/7kmxMNhL6T aQ3l7O82/bLY6h9/dPwRIeBoooNDheX+qPf9mzmRspC5TJEA/4tEsUIDyjL9HDoYbCOB V2L37tuNWMih9PYDgTSK6zUH602cEJpx5nZ2HQ97S3cB2ZxoPiWQezkjdB29038ML2J9 0kCGuiRZ3mUxxJj5jWNKmSGyujjcEdMP/Lev8+O9qImIg4VJbeLiqbo/86Tuost+f2Oi 2prg== X-Gm-Message-State: AOJu0Yzcf/qRD7EfUOpmx2hcKL0NDJV+wNt6XIGxRJ2sUgOYcq6NItVt 9DPjVNAbkZacy8VTPSyCnQkULKPhCVULDtel2YTW5I1Ncs8gZh4Gxt2kmOeh14hNo1GbeOFh9cs PTQYCI5f27pPfz7cmsq5dNmMFLVCFMtY= X-Gm-Gg: ATEYQzxP3brB9ywzom42Fi+i0wbHdGnJ+g0H/vOGStdDbJBdRF3BC8L05MSPiDyGNMp 0iC7z+eismXiucOPy4FrrXXwAUXYvTfXTE0rQpmvlH3RnYQD4IZQjD2+O6IjuWev3gxfoVb9xr5 C2QCppiQSpuRW2yjvdf9MVq1E5sMhl9MEOeRI8FFQoshD5BbSYPK592pBcfEwjAuUTWp/IrHvB/ Ny+DW+R650vK7X5Ovvjc6ayKzmJugO6VX+GAwDOnMh6Hhygz6qm3RnbomnZeJk9vGcESh4m5bDh PI/9Kj8= X-Received: by 2002:a05:6820:618:b0:65d:1336:f667 with SMTP id 006d021491bc7-679faf4cfeemr1977023eaf.54.1772201560259; Fri, 27 Feb 2026 06:12:40 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a8a:1344:0:b0:622:3fb7:b404 with HTTP; Fri, 27 Feb 2026 06:12:39 -0800 (PST) In-Reply-To: References: From: "David G. Johnston" Date: Fri, 27 Feb 2026 07:12:39 -0700 X-Gm-Features: AaiRm53RFMqzkPX2-nfz9W5_0imfe8t90Obt8tbWKczOqC16c4M23c24QEyj49s Message-ID: Subject: Re: A suggestion about the usage manual of \d command To: yuanchao zhang Cc: "pgsql-docs@lists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000784192064bced4ee" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000784192064bced4ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, February 27, 2026, yuanchao zhang wrote: > Hi, > I created a domain object named `numeric` using the following statement: > `CREATE DOMAIN numeric AS NUMERIC(12,2) DEFAULT 0 CHECK (VALUE >=3D 0);` > After executing this SQL, it indicated that the domain was created > successfully. However, when I executed `\dD` in psql, the created domain > could not be displayed. > > The reason is that the name I used is the same as a built-in type (of > course, similar issues exist not only with domains). However, our manual > for the `\dD` command lacks relevant explanations, which can mislead user= s. > Users might think an object was successfully created, but the `\d` comman= d > doesn't display it, which could make beginners doubt whether the object w= as > created successfully. I suggest adding necessary explanations to the `\d` > command's manual. > As explained in your bug report the documentation already covers namespaces, types, and the pattern argument to the \d meta commands. Covering all of that within the scope of the specific =E2=80=9C\dD=E2=80=9D= meta command to explain your example case is very unappealing. I honestly don=E2=80=99t se= e this going anywhere unless you propose specific text and location suggestions for what such a patch should look like. A real patch is even better, but with solid enough ideas someone might volunteer to bundle it all into sgml format. David J. --000000000000784192064bced4ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, February 27, 2026, yuanchao zhang <zhangyc0706@gmail.com> wrote:
Hi,
I created a domain object named `= numeric` using the following statement: `CREATE DOMAIN numeric AS NUMERIC(1= 2,2) DEFAULT 0 CHECK (VALUE >=3D 0);` After executing this SQL, it indic= ated that the domain was created successfully. However, when I executed `\d= D` in psql, the created domain could not be displayed.

The reason is= that the name I used is the same as a built-in type (of course, similar is= sues exist not only with domains). However, our manual for the `\dD` comman= d lacks relevant explanations, which can mislead users. Users might think a= n object was successfully created, but the `\d` command doesn't display= it, which could make beginners doubt whether the object was created succes= sfully. I suggest adding necessary explanations to the `\d` command's m= anual.

As explained in your bug repor= t the documentation already covers namespaces, types, and the pattern argum= ent to the \d meta commands.=C2=A0 Covering all of that within the scope of= the specific =E2=80=9C\dD=E2=80=9D meta command to explain your example ca= se is very unappealing.=C2=A0 I honestly don=E2=80=99t see this going anywh= ere unless you propose specific text and location suggestions for what such= a patch should look like.=C2=A0 A real patch is even better, but with soli= d enough ideas someone might volunteer to bundle it all into sgml format.

David J.

--000000000000784192064bced4ee--