Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
That would cripple a system that many users are perfectly content with now.
Well, I wasn't thinking of using a 7-bit encoding always, just as a
replacement for the cases where we currently choose SQL_ASCII.
On Fri, May 13, 2005 at 01:15:36AM -0400, Tom Lane wrote:
We are currently seeing a whole lot of complaints due to the fact that
8.0 tends to default to Unicode encoding in environments where previous
versions defaulted to SQL-ASCII. That says to me that a whole lot of
people were getting
Alvaro Herrera [EMAIL PROTECTED] writes:
The problem is that a single application coming from a single
environment is happy with a 8-bit-unchecked encoding, but as soon as
they develop a second application using a different environment, which
uses a different encoding, they start seeing
Alvaro Herrera [EMAIL PROTECTED] writes:
In fact I've seen many more people with this problem after 8.0 was
released, at least in pgsql-es-ayuda.
Which problem exactly? Most of the 8.0 complaints I can recall seemed
to come from people who were trying to dump from a SQL_ASCII database
and
On Fri, May 13, 2005 at 09:59:27AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
The problem is that a single application coming from a single
environment is happy with a 8-bit-unchecked encoding, but as soon as
they develop a second application using a different
Tom Lane wrote:
We should wait and see what field experience is like with
that, rather than insisting on anything as anal-retentive as disallowing
8-bit data in SQL_ASCII.
I didn't suggest changing the behaviour of SQL_ASCII..
-O
---(end of
On Fri, May 13, 2005 at 10:22:06AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
In fact I've seen many more people with this problem after 8.0 was
released, at least in pgsql-es-ayuda.
Which problem exactly? Most of the 8.0 complaints I can recall seemed
to come from
Am Donnerstag, 12. Mai 2005 04:42 schrieb Oliver Jowett:
I suppose that we can't change the semantics of SQL_ASCII without
backwards compatibility problems. I wonder if introducing a new encoding
that only allows 7-bit ascii, and making that the default, is the way to
go.
In 8.0, the de facto
In 8.0, the de facto default encoding is no longer SQL_ASCII, so that problem
should go away over time. Certainly, making 7-bit ASCII the default encoding
is not an option.
You sure?
---(end of broadcast)---
TIP 7: don't forget to increase your
Personally, I'd like UTF8 to be the default encoding :) This
is the 21st century :D
I concur.
... John
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Peter Eisentraut wrote:
Am Donnerstag, 12. Mai 2005 04:42 schrieb Oliver Jowett:
I suppose that we can't change the semantics of SQL_ASCII without
backwards compatibility problems. I wonder if introducing a new encoding
that only allows 7-bit ascii, and making that the default, is the way to
Oliver Jowett [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
In 8.0, the de facto default encoding is no longer SQL_ASCII, so that
problem should go away over time.
My 8.0.0 (what I happen to have on hand) initdb creates a SQL_ASCII
cluster by default unless I specify -E.
This would
Am Donnerstag, 12. Mai 2005 14:57 schrieb Oliver Jowett:
My 8.0.0 (what I happen to have on hand) initdb creates a SQL_ASCII
cluster by default unless I specify -E.
Then you use the locale C. We could create a 7-bit encoding and map it to
locale C, I suppose.
Certainly, making 7-bit ASCII
Peter Eisentraut wrote:
Am Donnerstag, 12. Mai 2005 14:57 schrieb Oliver Jowett:
My 8.0.0 (what I happen to have on hand) initdb creates a SQL_ASCII
cluster by default unless I specify -E.
Then you use the locale C. We could create a 7-bit encoding and map it to
locale C, I suppose.
Oliver Jowett [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
That would cripple a system that many users are perfectly content with now.
Well, I wasn't thinking of using a 7-bit encoding always, just as a
replacement for the cases where we currently choose SQL_ASCII. Does that
sound
We are currently seeing a whole lot of complaints due to the fact that
8.0 tends to default to Unicode encoding in environments where previous
versions defaulted to SQL-ASCII. That says to me that a whole lot of
people were getting along just fine in SQL-ASCII, and therefore that
moving further
The SQL_ASCII-breaks-JDBC issue just came up yet again on the JDBC list,
and I'm wondering if we can do something better on the server side to
help solve it.
The problem is that people have SQL_ASCII databases with non-7-bit data
in them under some encoding known only to a (non-JDBC) application.
I suppose that we can't change the semantics of SQL_ASCII without
backwards compatibility problems. I wonder if introducing a new encoding
that only allows 7-bit ascii, and making that the default, is the way to
go.
A while back I requested a new encoding that is '7BITASCII'. It would
be
Dennis Björklund writes:
Why do we have SQL_ASCII?
It gives a simple default behavior for people who don't want to deal with
character set issues.
I could understand it if we only could store 7-bit strings there. But
SQL_ASCII lets you store 8-bit values. Should I understand SQL_ASCII
Why do we have SQL_ASCII?
I could understand it if we only could store 7-bit strings there. But
SQL_ASCII lets you store 8-bit values. Should I understand SQL_ASCII
simply as 8-bit strings of unknown charset?
In the first database I created I used it to store latin1 strings, and
that was a
20 matches
Mail list logo
