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  (neha khatri <nehakhatri5@gmail.com>)
Список 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.

Carol 

Sent from my iPad

On Feb 13, 2017, at 7:41 AM, neha khatri <nehakhatri5@gmail.com> wrote:


 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 
convert before such transfer happens?

Regards,
Neha 

В списке pgsql-novice по дате отправления:

Предыдущее
От: neha khatri
Дата:
Сообщение: Re: [NOVICE] Regression test : pg_conversion validation
Следующее
От: neha khatri
Дата:
Сообщение: Re: [NOVICE] Regression test : pg_conversion validation