From: | Alvaro Herrera <alvherre(at)atentus(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Sullivan <andrew(at)libertyrms(dot)com>, PostgreSQL general list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: moving char() to varchar() |
Date: | 2001-09-07 21:07:11 |
Message-ID: | Pine.LNX.4.33L2.0109071706070.5974-100000@aguila.protecne.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 7 Sep 2001, Tom Lane wrote:
> Andrew Sullivan <andrew(at)libertyrms(dot)com> writes:
> > 1. I thought the SQL spec required varchar() not to pad. Is it
> > just that, because of the way pg_dump saved the char() data (as
> > blank-padded) that the varchar() field preserves the padded data?
>
> You could possibly make an argument that trailing blanks in a char()
> column (which ARE known to be padding) should be stripped during dumping,
> primarily for convenience in reloading into varchar columns. But this
> seems a tad weird and unexpected to me. An explicit trim() operation
> sounds like a better idea.
Maybe you can modify the pg_dump source to use trim() on the output
columns when given a --trim-char-columns :-)
--
Alvaro Herrera (<alvherre[(at)]atentus(dot)com>)
From | Date | Subject | |
---|---|---|---|
Next Message | Haroldo Stenger | 2001-09-07 21:19:01 | Abort state on duplicated PKey in transactions |
Previous Message | Alvaro Herrera | 2001-09-07 21:05:22 | Re: What Is The Firing Order? |