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 co
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 broadcast)---
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 e
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 r
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 i
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
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 choos
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 aw
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
> soun
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 sup
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 AS
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 wo
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 wa
> 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
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 fre
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 fa
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 excellen
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.
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
> si
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 mist
20 matches
Mail list logo
