Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1khab5-00053f-LL for pgsql-bugs@arkaria.postgresql.org; Tue, 24 Nov 2020 15:51:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1khab4-0004Ca-K4 for pgsql-bugs@arkaria.postgresql.org; Tue, 24 Nov 2020 15:51:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1khab4-0004CT-EA for pgsql-bugs@lists.postgresql.org; Tue, 24 Nov 2020 15:51:14 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1khab0-0004We-G6 for pgsql-bugs@lists.postgresql.org; Tue, 24 Nov 2020 15:51:14 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1khaaw-00068o-TV; Tue, 24 Nov 2020 10:51:06 -0500 Date: Tue, 24 Nov 2020 10:51:06 -0500 From: Bruce Momjian To: Tom Lane Cc: turon.david@seznam.cz, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #16743: psql doesn't show whole expression in stored column Message-ID: <20201124155106.GE29448@momjian.us> References: <16743-7b1bacc4af76e7ad@postgresql.org> <286182.1606232817@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <286182.1606232817@sss.pgh.pa.us> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, Nov 24, 2020 at 10:46:57AM -0500, Tom Lane wrote: > PG Bug reporting form writes: > > when generated column expression length is larger then some value - the rest > > of expression is cut in \d[+] output: > > Yeah, this is an intentional and very ancient behavior: > > appendPQExpBufferStr(&buf, > ",\n (SELECT substring(pg_catalog.pg_get_expr(d.adbin, d.adrelid, true) for 128)" > "\n FROM pg_catalog.pg_attrdef d" > > Maybe we should decide that completeness is more important than keeping > the line to some arbitrary width. But it's operating as designed. I think I am fine with the current behavior. If you run psql with -E, you can see the queries it generates: SELECT a.attname, pg_catalog.format_type(a.atttypid, a.atttypmod), --> (SELECT substring(pg_catalog.pg_get_expr(d.adbin, d.adrelid, true) for 128) --------- ------- FROM pg_catalog.pg_attrdef d WHERE d.adrelid = a.attrelid AND d.adnum = a.attnum AND a.atthasdef), a.attnotnull, (SELECT c.collname FROM pg_catalog.pg_collation c, pg_catalog.pg_type t WHERE c.oid = a.attcollation AND t.oid = a.atttypid AND a.attcollation <> t.typcollation) AS attcollation, a.attidentity, a.attgenerated FROM pg_catalog.pg_attribute a WHERE a.attrelid = '16385' AND a.attnum > 0 AND NOT a.attisdropped ORDER BY a.attnum; -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee