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 1mBdSZ-00033b-5r for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Aug 2021 13:30:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mBdSY-00029U-4D for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Aug 2021 13:30:54 +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 1mBdSX-00029J-R2 for pgsql-hackers@lists.postgresql.org; Thu, 05 Aug 2021 13:30:53 +0000 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mBdSV-00044F-KO for pgsql-hackers@lists.postgresql.org; Thu, 05 Aug 2021 13:30:53 +0000 Received: by mail-lf1-x131.google.com with SMTP id bq29so11131231lfb.5 for ; Thu, 05 Aug 2021 06:30:50 -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=js0Co/NLCRS70Cne9x5y/IzjamagoJgbTlFmYsC7MDE=; b=DMrnudw2jeKPJBB9YdeLNchkeGkbrQChhutrAVv8ChFrpGQG7ybYbwnCxikU9qJrrf EhVBMaBPG58EQhGAEuHgn4uVYQ4JZ3DA7eH50XQ0a3Ii7voA/1nOg0AXzHCq4ixKZ5KO 8UBEjga72wtknyeWzQGM0cIi0BegCsfa6QjWC7e5lPNBj2Arlwsfuwk4GaUo9KIbvABD skX2VayyZf3VycKrcsaxhgz9lLGGcRHLUCP9NgApP9LIaMkgm5C6XYh+7xm6YETkjWkQ 3rGWMbl6/PrhW6IRBr4TKFPw9SeTBBydpUV271VA5TswQd2CB1TyuWqP5EhXlE3d6DWY ghwA== 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=js0Co/NLCRS70Cne9x5y/IzjamagoJgbTlFmYsC7MDE=; b=dlv5/9ilhHcuqoW6GMf1LXSXEQwKDpgyycN0BYhQVdPebnLfMmPvUbAMWXLlLyTG0c jQccjT1FTlUbsGl/YhOCw+UjKEy0v9h7ugKPxNyc01w8roPQYZm7qC3hMXxbJ1Q9CTlL QrHjyX+hyDD3lYUWyqy2fdKep/C0DL+6X7zKdGSkrpCYx7lJfR95dA+jFc4qjaQTIbEL PTPS/8JT9DupWqDnRBy+FR9OLm/48p3fpkzNkRZIZajvA0ICL9ZSTRnan/xzr1W1/CKR /oU/LIwkJv0xmSbnQMrmZnFsOPc6I0id6Kvj+XxdVMRJxsgssGFdAgFd+fETnuo7l1GV E2NQ== X-Gm-Message-State: AOAM533hM/aIL4U6k+YXcAXd0cr2vcLhmz0sHNLFwRnCyCoPBXx9Sk/o ggmuLsmx2DJHrnDlfzjS7rWfxCkXbvM= X-Google-Smtp-Source: ABdhPJwsi73curTWMpL4MT63c6u/lla+paQehYxrNsjUybGu5w+IV29CK5F3qu+PFxKkXkdWW+nNvg== X-Received: by 2002:ac2:58f4:: with SMTP id v20mr3775405lfo.87.1628170249894; Thu, 05 Aug 2021 06:30:49 -0700 (PDT) Received: from [192.168.1.3] ([46.138.249.39]) by smtp.gmail.com with ESMTPSA id p5sm516516lfo.254.2021.08.05.06.30.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Aug 2021 06:30:49 -0700 (PDT) Subject: Re: very long record lines in expanded psql output To: Pavel Stehule Cc: PostgreSQL Hackers References: <27f30f68-c4bd-2f02-080c-8feb0b6eded3@gmail.com> From: Platon Pronko Message-ID: Date: Thu, 5 Aug 2021 16:30:48 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi! > a) with line cursor Tried in different configurations, seems that line cursor works fine. > b) format detection - I try to detect the header line - and I expect this > line has the most length of all lines. I use a line with the same length as > the column's type info (data, border). I looked at pspg source, and here's what I found (please correct me if some/all of my assumptions are wrong): 1. Input handling and format detection happens in table.c readfile(). 2. There's some variables in DataDesc - maxx and maxbytes - that store the longest line seen so far. But they are re-updated on each new row, so the fact that header is shorter shouldn't affect them. 3. Expanded header detection is handled by is_expanded_header function. It has ei_minx and ei_maxx return pointers, but when it is used from readfile() these pointers are set to NULL in both cases - so header length is simply ignored. > Did you test the wrapped format? It is working > > \pset format wrapped > \x > select * from pg_class; There's no difference in outputs in wrapped format, so pspg behavior is also unaffected. By the way, it seems that pspg recommends setting \pset border 2 anyway, so in vast majority of cases there should be no possibility of difference at all - proposed patch doesn't change output for \pset border 2 (because there's no sane way of making it look okay in presence of long fields anyway). Best regards, Platon Pronko