From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | postgann2020 s <postgann2020(at)gmail(dot)com> |
Cc: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Help to find-the-maximum-length-of-field-in-a-particular-column-in-all the tables |
Date: | 2020-04-03 07:25:50 |
Message-ID: | CAKFQuwZV2-r8Z4yV1OHOssqL+coW_c0t2tUySRPbMkyymTW7dw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-general |
On Thu, Apr 2, 2020 at 10:15 PM postgann2020 s <postgann2020(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Bernstein | 2020-04-03 16:35:26 | How to get off the email list? |
Previous Message | Julien Rouhaud | 2020-04-03 07:03:16 | Re: Can we extract CPU usage by table/query level |
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Cross | 2020-04-03 07:27:11 | Re: Improve COPY performance into table with indexes. |
Previous Message | David G. Johnston | 2020-04-03 07:17:55 | Re: Fixing set-returning functions are not allowed in UPDATE after upgrade to Postgres 12 |