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 1mCNkU-0003hX-9E for pgsql-hackers@arkaria.postgresql.org; Sat, 07 Aug 2021 14:56:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mCNkR-0006vy-JZ for pgsql-hackers@arkaria.postgresql.org; Sat, 07 Aug 2021 14:56:27 +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 1mCNkR-0006vp-8x for pgsql-hackers@lists.postgresql.org; Sat, 07 Aug 2021 14:56:27 +0000 Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mCNkO-0008Pt-ON for pgsql-hackers@lists.postgresql.org; Sat, 07 Aug 2021 14:56:26 +0000 Received: by mail-lj1-x231.google.com with SMTP id h17so5226831ljh.13 for ; Sat, 07 Aug 2021 07:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bprkKfKomOjMjEbAVhfYD3gH3OzfGaLUt3oUV7m7zQ0=; b=Cvodz6Ea1QcwNJe4K8sliL5tjnDhPFYagxg/MaSUQqF+7Ehwhs6omTxrAVv5D2kR2u +m1vnNrrT5xRjof8VqItauMx02Vw7S4E/vKaBQjLqbu9w5Lwv/Jz2VlKJFWGNMrG7MdH ObWBQ13zg+EAehYlRKSVl952r/qe6SjQqtheXmg1sL3JgsbzC6sStu59KWVwEbulAy0a TGZbc/AnKjUliFrx5H6nWj+79fkzzH3u55TFCBfLMyKdo6Z9PT4Spu+j+wOtAGIWoMg1 RjNwN+76pPw9ekJ7xpk0xoaTk3YW85bK3tzCsDWdgu1Rx0YAbwJ91R4HFzy11o14sfMr 3WvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bprkKfKomOjMjEbAVhfYD3gH3OzfGaLUt3oUV7m7zQ0=; b=VyRm7S+ln2o8sNLd13Yy6tHcp03HytSBdJ7BA57VE/8wTiGLN5ol1tlF8MCTe3xlqx urWL5KGi+YT1idvtiSawei4faIgSJGj0ogVHSnMYW4W6Q1dE3oQitwND/0MYKCDxAfhh qG4ErPXssJcLnlR0gDhZ284jbWnodthwr2GhMtmqcFNNurX4Ch+8z0+sX6dV7V39WS10 8C3onNqTsMQGxOK2lQg/A8OCdiS6o5F+4lXEn2LRDSOluTrYYGHEG1Blq8+6C2D71Df6 zFqGqeQ5qVj+uMTy0sp2adT5/MWrokBmorTfsa0rjC1Co7qvtcgIupLy7KeHf1vZMg9N vLmQ== X-Gm-Message-State: AOAM5319hmAV5/T6YONxKV6uYNDuX/xRWsZThtDSaBhbslJwqXQBEm0s tqFootyEBGFK/uzBXY1TwA8xqU7j+4A= X-Google-Smtp-Source: ABdhPJy3f3u29VQfWAkjHLUKGQ2YP8YjVmAEO2VrDYlHpNL6syiBwHJBWISpWK7MgVYjH4ElGvklcw== X-Received: by 2002:a2e:3006:: with SMTP id w6mr10182908ljw.178.1628348183528; Sat, 07 Aug 2021 07:56:23 -0700 (PDT) Received: from [192.168.1.3] ([46.138.249.39]) by smtp.gmail.com with ESMTPSA id 4sm983999ljf.127.2021.08.07.07.56.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Aug 2021 07:56:23 -0700 (PDT) Subject: Re: very long record lines in expanded psql output To: Andrew Dunstan Cc: PostgreSQL Hackers References: <998a8549-f808-a349-bae6-9f44d07e050d@dunslane.net> <4e8b9a10-95aa-aecf-01a1-cbc24d643465@gmail.com> <66d23848-9f73-abc9-2fbb-3b8abfbb2fce@dunslane.net> From: Platon Pronko Message-ID: <0efd52b9-450a-7636-fb75-663bc2d81b34@gmail.com> Date: Sat, 7 Aug 2021 17:56:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <66d23848-9f73-abc9-2fbb-3b8abfbb2fce@dunslane.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi! >>>>> I also find this annoying and would be happy to be rid of it. >>>> >>>> Have you tried "\pset format wrapped"? Pavel suggested it, and it >>>> solved most of the problem for me, for example. >>> >>> Yes, but it changes the data line output. Ideally, you should be able >>> to  modify these independently. >> >> I agree, and I think this can be implemented, but I'm a bit afraid of >> introducing an additional psql option (there's already quite a lot of >> them). >> I suspect primary PostgreSQL maintainers won't be happy with such an >> approach. >> >> > > I think I qualify as one of those ... :-) Sorry, I'm new here, don't know who's who :) I'll start working on a new patch then. A couple questions about specifics: 1. Can we add "expanded" in the option name, like "xheader_expanded_width"? I think adjusting the header row width doesn't make sense on any other modes, and placing that in the option name makes intent a bit clearer. 2. What was "column" option in your original suggestion supposed to do? ("\pset xheader_width column|page|nnn") 3. Should we bother with using this option when in "\pset border 2" mode? I can do it for consistency, but it will still look bad. Best regards, Platon Pronko