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.
On Mon, Feb 13, 2017 at 6:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
neha khatri <nehakhatri5@gmail.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
