Re: Regression test : pg_conversion validation

I'm not sure why this would be a problem. Postgres isn't going to run on the EBCDIC machine so the data will just have to be run through a code inverter going back an forth.
There are many of them available for this kind of application.

Carol

Sent from my iPad

> On Feb 13, 2017, at 7:41 AM, neha khatri <nehakhatri5(at)gmail(dot)com> wrote:
>
>
>> 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