Re: What's a correct or good Encoding for Postgres 9.1.2?

Started by Khangelani Gamaalmost 14 years ago5 messagesgeneral
Jump to latest
#1Khangelani Gama
kgama@argility.com

Hi

Please assist, I am junior DBA. We are upgrading from postgres 7.3.4 where
we were using SQL_ASCII Encoding to Postgres 9.1.2. It looks like Postgres
9.1.2 forces you to use UTF8 Encoding if I read from this link
http://www.postgresql.org/docs/9.1/static/release-9-1-2.html . Can we still
use SQL_ASCII in postgres 9.1.2?

Your help will bemuch appreciated.

Regards,

Khangelani Gama

CONFIDENTIALITY NOTICE
The contents of and attachments to this e-mail are intended for the addressee only, and may contain the confidential information of Argility (Proprietary) Limited and/or its subsidiaries. Any review, use or dissemination thereof by anyone other than the intended addressee is prohibited.
If you are not the intended addressee please notify the writer immediately and destroy the e-mail. Argility (Proprietary) Limited and its subsidiaries distance themselves from and accept no liability for unauthorised use of their e-mail facilities or e-mails sent other than strictly for business purposes.

#2gelin yan
dynamicgl@gmail.com
In reply to: Khangelani Gama (#1)

On Wed, May 30, 2012 at 11:58 PM, Khangelani Gama <kgama@argility.com>wrote:

Hi

Please assist, I am junior DBA. We are upgrading from postgres 7.3.4 where
we were using SQL_ASCII Encoding to Postgres 9.1.2. It looks like Postgres
9.1.2 forces you to use UTF8 Encoding if I read from this link
http://www.postgresql.org/docs/9.1/static/release-9-1-2.html . Can we
still use SQL_ASCII in postgres 9.1.2?

Your help will bemuch appreciated.

Regards,

Khangelani Gama

CONFIDENTIALITY NOTICE
The contents of and attachments to this e-mail are intended for the addressee only, and may contain the confidential information of Argility (Proprietary) Limited and/or its subsidiaries. Any review, use or dissemination thereof by anyone other than the intended addressee is prohibited.
If you are not the intended addressee please notify the writer immediately and destroy the e-mail. Argility (Proprietary) Limited and its subsidiaries distance themselves from and accept no liability for unauthorised use of their e-mail facilities or e-mails sent other than strictly for business purposes.

Hi

UTF-8 should be compatible with SQL_ASCII.

#3Khangelani Gama
kgama@argility.com
In reply to: gelin yan (#2)

Hi

We were getting this error.

ERROR: invalid byte sequence for encoding "UTF8": 0xa0

We are thinking of using SQL_ASCII in postgres 9.1.2

And that we will be feeding from backup server(UTF-8) into another server
that’s using SQL_ASCII. Where are not if it’ll be fine to feed from UTF-8
to SQL_ASCII.

Clear explaination:

We have

Primary server and the backup server running on postgres7.3.4 using
SQL_ASCII. And another server which is already on 9.1.2 already is using
SQL_ASCII. We feed the same data(from backup server) into this third server.

Now we are upgrading these two servers(primary and backup) to Postgres9.1.2
where we use UTF-8 encoding.

So talking about compatibility, you are saying we can continue using
UTF-8?, but this will create more work for us because most of our scripts
assume that encoding is SQL_ASCII hence we want continue using SQL_ASCII
in Postgres 9.1.2.

Thanks

*From:* pgsql-general-owner@postgresql.org [mailto:
pgsql-general-owner@postgresql.org] *On Behalf Of *gelin yan
*Sent:* Wednesday, May 30, 2012 6:59 PM
*To:* pgsql-general@postgresql.org
*Subject:* Re: [GENERAL] What's a correct or good Encoding for Postgres
9.1.2?

On Wed, May 30, 2012 at 11:58 PM, Khangelani Gama <kgama@argility.com>
wrote:

Hi

Please assist, I am junior DBA. We are upgrading from postgres 7.3.4 where
we were using SQL_ASCII Encoding to Postgres 9.1.2. It looks like Postgres
9.1.2 forces you to use UTF8 Encoding if I read from this link
http://www.postgresql.org/docs/9.1/static/release-9-1-2.html . Can we still
use SQL_ASCII in postgres 9.1.2?

Your help will bemuch appreciated.

Regards,

Khangelani Gama

CONFIDENTIALITY NOTICE

The contents of and attachments to this e-mail are intended for the
addressee only, and may contain the confidential information of
Argility (Proprietary) Limited and/or its subsidiaries. Any review,
use or dissemination thereof by anyone other than the intended
addressee is prohibited.

If you are not the intended addressee please notify the writer
immediately and destroy the e-mail. Argility (Proprietary) Limited and
its subsidiaries distance themselves from and accept no liability for
unauthorised use of their e-mail facilities or e-mails sent other than
strictly for business purposes.

Hi

UTF-8 should be compatible with SQL_ASCII.

CONFIDENTIALITY NOTICE
The contents of and attachments to this e-mail are intended for the addressee only, and may contain the confidential information of Argility (Proprietary) Limited and/or its subsidiaries. Any review, use or dissemination thereof by anyone other than the intended addressee is prohibited.
If you are not the intended addressee please notify the writer immediately and destroy the e-mail. Argility (Proprietary) Limited and its subsidiaries distance themselves from and accept no liability for unauthorised use of their e-mail facilities or e-mails sent other than strictly for business purposes.

#4John R Pierce
pierce@hogranch.com
In reply to: Khangelani Gama (#3)

On 05/30/12 10:17 AM, Khangelani Gama wrote:

So talking about compatibility, you are saying we can continue using
UTF-8?, but this will create more work for us because most of our
scripts assume that encoding is SQL_ASCII hence we want continue
using SQL_ASCII in Postgres 9.1.2.

SQL_ASCII is not really an encoding, its saying "this data has no
encoding at all, its just bytes". UTF-8 will reject any data thats not
properly UTF8 encoded.

converting from 'undefined' encoding to a rigorously enforced encoding
is problematic. On the other hand, working in SQL_ASCII has all kinda
ugly issues, like length(somestring) is just counting bytes, and not
characters if the string happens to be a multibyte encoded entity.
collation order is just binary. upper/lower don't work on anything
other than USASCII (eg, accented characters are ignored).

sounds to me like you're stuck in SQL_ASCII

--
john r pierce N 37, W 122
santa cruz ca mid-left coast

#5Khangelani Gama
kgama@argility.com
In reply to: John R Pierce (#4)

Many Thanks for feedback.

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of John R Pierce
Sent: Wednesday, May 30, 2012 7:54 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] What's a correct or good Encoding for Postgres
9.1.2?

On 05/30/12 10:17 AM, Khangelani Gama wrote:

So talking about compatibility, you are saying we can continue using
UTF-8?, but this will create more work for us because most of our
scripts assume that encoding is SQL_ASCII hence we want continue
using SQL_ASCII in Postgres 9.1.2.

SQL_ASCII is not really an encoding, its saying "this data has no
encoding at all, its just bytes". UTF-8 will reject any data thats not
properly UTF8 encoded.

converting from 'undefined' encoding to a rigorously enforced encoding is
problematic. On the other hand, working in SQL_ASCII has all kinda ugly
issues, like length(somestring) is just counting bytes, and not characters
if the string happens to be a multibyte encoded entity.
collation order is just binary. upper/lower don't work on anything
other than USASCII (eg, accented characters are ignored).

sounds to me like you're stuck in SQL_ASCII

--
john r pierce N 37, W 122
santa cruz ca mid-left coast

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make
changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

CONFIDENTIALITY NOTICE
The contents of and attachments to this e-mail are intended for the addressee only, and may contain the confidential information of Argility (Proprietary) Limited and/or its subsidiaries. Any review, use or dissemination thereof by anyone other than the intended addressee is prohibited.
If you are not the intended addressee please notify the writer immediately and destroy the e-mail. Argility (Proprietary) Limited and its subsidiaries distance themselves from and accept no liability for unauthorised use of their e-mail facilities or e-mails sent other than strictly for business purposes.