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 1khwKw-0007sf-QT for pgsql-bugs@arkaria.postgresql.org; Wed, 25 Nov 2020 15:04:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1khwKv-0004c0-0E for pgsql-bugs@arkaria.postgresql.org; Wed, 25 Nov 2020 15:04:01 +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 1khwKu-0004bt-QM for pgsql-bugs@lists.postgresql.org; Wed, 25 Nov 2020 15:04:00 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1khwKs-0007Ys-Ej for pgsql-bugs@lists.postgresql.org; Wed, 25 Nov 2020 15:04:00 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 0APF3rhK426715; Wed, 25 Nov 2020 10:03:53 -0500 From: Tom Lane To: Peter Eisentraut cc: turon.david@seznam.cz, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #16743: psql doesn't show whole expression in stored column In-reply-to: <7a1faa2c-d4d1-67fd-03fe-29ef7e240301@enterprisedb.com> References: <16743-7b1bacc4af76e7ad@postgresql.org> <286182.1606232817@sss.pgh.pa.us> <7a1faa2c-d4d1-67fd-03fe-29ef7e240301@enterprisedb.com> Comments: In-reply-to Peter Eisentraut message dated "Wed, 25 Nov 2020 09:38:03 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <426713.1606316633.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Nov 2020 10:03:53 -0500 Message-ID: <426714.1606316633@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Peter Eisentraut writes: > On 2020-11-24 16:46, Tom Lane wrote: >> 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 we should get rid of the truncating. Otherwise, there is no way= = > to actually get the full information, is there? (Other than pg_dump or = > manual catalog queries.) That'd be okay with me. It's always seemed a little odd that we do that for attrdefs but not anything else. A bit of checking with git blame says that the habit came in with the very first version of describe.c, in commit a45195a191eec367a4f305bb71ab541d17a3b9f9 Author: Bruce Momjian Date: Thu Nov 4 21:56:02 1999 +0000 Major psql overhaul by Peter Eisentraut. which has + /* Info */ + cells[i*cols + 2] =3D xmalloc(128 + 128); /* I'm cutting off the defa= ult string at 128 */ + cells[i*cols + 2][0] =3D '\0'; + if (strcmp(PQgetvalue(res, i, 4), "t") =3D=3D 0) + strcat(cells[i*cols + 2], "not null"); + if (strcmp(PQgetvalue(res, i, 5), "t") =3D=3D 0) { + /* handle "default" here */ + strcpy(descbuf, "SELECT substring(d.adsrc for 128) FROM pg_attrde= f d, pg_class c\n" + "WHERE c.relname =3D '"); So that looks very much like the truncation was an expedient thing to do to work with a fixed-size result buffer, rather than something that was chosen to improve the user experience. regards, tom lane