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 1khb8m-0006Oz-I4 for pgsql-bugs@arkaria.postgresql.org; Tue, 24 Nov 2020 16:26:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1khb8j-0000SK-Rv for pgsql-bugs@arkaria.postgresql.org; Tue, 24 Nov 2020 16:26:01 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1khb8j-0000SC-Cy for pgsql-bugs@lists.postgresql.org; Tue, 24 Nov 2020 16:26:01 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1khb8c-0002rO-TG for pgsql-bugs@lists.postgresql.org; Tue, 24 Nov 2020 16:26: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 0AOGPpdl287904; Tue, 24 Nov 2020 11:25:51 -0500 From: Tom Lane To: Bruce Momjian cc: turon.david@seznam.cz, pgsql-bugs@lists.postgresql.org, Peter Eisentraut Subject: Re: BUG #16743: psql doesn't show whole expression in stored column In-reply-to: <20201124155106.GE29448@momjian.us> References: <16743-7b1bacc4af76e7ad@postgresql.org> <286182.1606232817@sss.pgh.pa.us> <20201124155106.GE29448@momjian.us> Comments: In-reply-to Bruce Momjian message dated "Tue, 24 Nov 2020 10:51:06 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <287902.1606235151.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Nov 2020 11:25:51 -0500 Message-ID: <287903.1606235151@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Bruce Momjian writes: > On Tue, Nov 24, 2020 at 10:46:57AM -0500, 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 I am fine with the current behavior. It's less great in the context of a GENERATED column. As things stand, the psql-side code wraps the truncated result into some more syntax: else if (generated[0] =3D=3D ATTRIBUTE_GENERATED_STORED) default_str =3D psprintf("generated always as (%s) stored"= , PQgetvalue(res, i, attrdef_col)); else /* (note: above we cut off the 'default' string at 128) */ default_str =3D PQgetvalue(res, i, attrdef_col); which seems distinctly more confusing than just truncating the result. So maybe there's justification here for revisiting that ancient decision. One could also imagine not appending ") stored" if the attrdef value appears to have been truncated --- although encoding-conversion effects would make it hard to tell that for sure. Perhaps we'd be better off to move the truncation logic to the psql side? Another thing here, which is undeniably a bug, is that that psprintf result is promptly leaked. regards, tom lane