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 1khxsW-0006bV-J1 for pgsql-bugs@arkaria.postgresql.org; Wed, 25 Nov 2020 16:42:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1khxsV-0005Q0-AK for pgsql-bugs@arkaria.postgresql.org; Wed, 25 Nov 2020 16:42:47 +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 1khxsV-0005Ps-4T for pgsql-bugs@lists.postgresql.org; Wed, 25 Nov 2020 16:42:47 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1khxsS-0006B5-Ub for pgsql-bugs@lists.postgresql.org; Wed, 25 Nov 2020 16:42:46 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1khxsO-0004Wh-Gc; Wed, 25 Nov 2020 11:42:40 -0500 Date: Wed, 25 Nov 2020 11:42:40 -0500 From: Bruce Momjian To: Tom Lane Cc: Peter Eisentraut , turon.david@seznam.cz, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #16743: psql doesn't show whole expression in stored column Message-ID: <20201125164240.GA26300@momjian.us> References: <16743-7b1bacc4af76e7ad@postgresql.org> <286182.1606232817@sss.pgh.pa.us> <7a1faa2c-d4d1-67fd-03fe-29ef7e240301@enterprisedb.com> <426714.1606316633@sss.pgh.pa.us> <464990.1606320939@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <464990.1606320939@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 Wed, Nov 25, 2020 at 11:15:39AM -0500, Tom Lane wrote: > I wrote: > > Peter Eisentraut writes: > >> 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. > > Here's a proposed patch for that. > > After looking a bit closer, I saw that the memory leak I was worried > about before is not real, because the code passes mustfree = true to > printTableAddCell. However, I still don't like it one bit, because you > need some undocumented and fragile assumptions about the relationship > between attidentity and attgenerated to conclude that we won't instead > have a false free() attempt on something that mustn't be free'd. So I > think we should adjust the code to track mustfree explicitly, as done > below. > > Should we back-patch this? I think that the truncation behavior became > significantly more of a problem with the addition of the GENERATED > feature; before that it was clearer what was going on. So I'm mildly > inclined to back-patch to v12 where that came in. Works for me. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee