From: | neha khatri <nehakhatri5(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: Regression test : pg_conversion validation |
Date: | 2017-02-13 12:41:45 |
Message-ID: | CAFO0U+_hXZLwkQ3KxD4hzWP0xx_vpqEBOpZDdvH_S4RiJcr47Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
On Mon, Feb 13, 2017 at 6:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> neha khatri <nehakhatri5(at)gmail(dot)com> writes:
> > It looks like this validation might not reflect the correct behaviour
> for a
> > well defined conproc for certain encodings.
> > e.g. Consider LATIN1 as src_encoding and EBCDIC as dst_encoding in the
> > above query.
>
> Um ... well, that's already a bridge too far. Postgres does not support
> any encodings that aren't ASCII supersets, and the possibility that we
> would do so in future isn't measurably different from zero. There's too
> much code that depends on that assumption, and too little benefit to
> getting rid of it.
>
> If you can show a problem case that doesn't involve EBCDIC, then I'm
> all ears.
>
Can't find another encoding, that isn't superset of ASCII.
But how PostgreSQL deals with data movement from EBCDIC machine to
ASCII machine. Would it be the applications responsibility to appropriately
convert before such transfer happens?
Regards,
Neha
From | Date | Subject | |
---|---|---|---|
Next Message | Carol Walter | 2017-02-13 12:57:21 | Re: Regression test : pg_conversion validation |
Previous Message | Tom Lane | 2017-02-13 07:27:11 | Re: Regression test : pg_conversion validation |