Re: [NOVICE] Regression test : pg_conversion validation
От | Carol Walter |
---|---|
Тема | Re: [NOVICE] Regression test : pg_conversion validation |
Дата | |
Msg-id | 675B560A-6003-4BDB-917C-E6F904787421@sbcglobal.net обсуждение исходный текст |
Ответ на | Re: [NOVICE] Regression test : pg_conversion validation (neha khatri <nehakhatri5@gmail.com>) |
Ответы |
Re: [NOVICE] Regression test : pg_conversion validation
|
Список | pgsql-novice |
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.
There are many of them available for this kind of application.
Carol
Sent from my iPad
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 toASCII machine. Would it be the applications responsibility to appropriatelyconvert before such transfer happens?Regards,Neha
В списке pgsql-novice по дате отправления: