Re: Help to find-the-maximum-length-of-field-in-a-particular-column-in-allthe tables - Mailing list pgsql-admin

From postgann2020 s
Subject Re: Help to find-the-maximum-length-of-field-in-a-particular-column-in-allthe tables
Date
Msg-id CANynezNM1bDVBGkdvv08mn3CrX0CR0feHBNNZBatQ4EFJEg0aA@mail.gmail.com
Whole thread Raw
In response to Re: Help to find-the-maximum-length-of-field-in-a-particular-column-in-allthe tables  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-admin
Got it David. 
Thanks I will try.

On Fri, Apr 3, 2020, 12:56 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Thu, Apr 2, 2020 at 10:15 PM postgann2020 s <postgann2020@gmail.com> wrote:
We are trying to findout the max size of the data in columns for all tables to resize the width of the assigned columns.

If you forgo brute force you will need to combine catalog access with dynamic SQL.  I'm not offering to work out the specific syntax for you.  If you've no better place to start the pl/pgsql documentation works as a language that provides this capability.  The main problem you are solving is that identifiers (e.b., table and column names) in select queries must be provided in the query text so you need to insert them (ideally using the "format()" function and "%I (eye)" placeholder.

I feel it bears repeating that this exercise seems like a poor one to perform (admittedly with zero actual knowledge as to the underlying situation).  Resizing them to "no size restriction" (i.e., "col_name text") would be my preference.  Higher risk fields might warrant constraints that check content in addition to (or in lieu of) length.  That fact that you are wanting to perform this exercise in the first place would be sufficient evidence that the previous decision to have field length limits was a poor one.  That my 0.02

David J.

pgsql-admin by date:

Previous
From: Mark Steben
Date:
Subject: postgres performance on azure
Next
From: Axel Rau
Date:
Subject: NEEDING HELP: dropping none-existing extension