From: | Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, turon(dot)david(at)seznam(dot)cz, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #16743: psql doesn't show whole expression in stored column |
Date: | 2020-11-25 09:25:29 |
Message-ID: | CACACo5ROCEEMa4WXMwngYJupd=STfG1Uzwes4evWZmgYba_9=w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Nov 25, 2020 at 10:19 AM Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> On 2020-11-24 16:46, Tom Lane wrote:
> > PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> >> when generated column expression length is larger then some value - the
> rest
> >> of expression is cut in \d[+] output:
> >
> > Yeah, this is an intentional and very ancient behavior:
> >
> > appendPQExpBufferStr(&buf,
> > ",\n (SELECT
> substring(pg_catalog.pg_get_expr(d.adbin, d.adrelid, true) for 128)"
> > "\n FROM pg_catalog.pg_attrdef d"
> >
> > Maybe we should decide that completeness is more important than keeping
> > the line to some arbitrary width. But it's operating as designed.
>
> 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.)
>
Either that or we have to make it clear that the output is truncated:
otherwise it can be mighty confusing.
--
Alex
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-11-25 14:06:25 | Re: segfault with incremental sort |
Previous Message | Amit Kapila | 2020-11-25 08:55:04 | Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop |