[BUGS] BUG #3819: UTF8 can't handle \000
The following bug has been logged online: Bug reference: 3819 Logged by: Franklin Schmidt Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: XP & Linux Description:UTF8 can't handle \000 Details: Trying to store \000 in a text field with UTF8 encoding causes an error. I assume this is because Postgres is written in C, but it's still wrong. A solution was suggested here: http://www.nabble.com/invalid-byte-sequence-for-encoding-%22UTF8%22%3A-0x00- tp9058998p9096326.html "I can think of some ways the server could support it without extensive changes .. e.g. use a modified UTF8 representation which stores \u as 0xc0 0x80 internally" ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #3820: auto-installer-failed
The following bug has been logged online: Bug reference: 3820 Logged by: Sergey Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.beta4 Operating system: Windows Vista x64 Description:auto-installer-failed Details: I have 8.2 version work and running, also I want to try out 8.3.beta4 but it failed to install. Windows logs tells: Activation content creation error for "C:\Program Files (x86)\PostgreSQL\8.3-beta4\bin\initdb.exe". There is no "Microsoft.VC80.CRT,processorArchitecture="x86"". ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3819: UTF8 can't handle \000
Franklin Schmidt wrote: > > The following bug has been logged online: > > Bug reference: 3819 > Logged by: Franklin Schmidt > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2 > Operating system: XP & Linux > Description:UTF8 can't handle \000 > Details: > > Trying to store \000 in a text field with UTF8 encoding causes an error. I > assume this is because Postgres is written in C, but it's still wrong. A > solution was suggested here: > > http://www.nabble.com/invalid-byte-sequence-for-encoding-%22UTF8%22%3A-0x00- > tp9058998p9096326.html > > "I can think of some ways the server could support it without extensive > changes .. e.g. use a modified UTF8 representation which stores \u as > 0xc0 0x80 internally" Uh, as far as I know 0x00 is not a valid UTF8 byte value. I suggest you use bytea to store 0x00. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3819: UTF8 can't handle \000
Franklin Schmidt wrote: > On Dec 17, 2007 12:54 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > > > Uh, as far as I know 0x00 is not a valid UTF8 byte value. > > > I think it is a valid value. RFC 3629 says: > > "Character numbers from U+ to U+007F (US-ASCII repertoire) > correspond to octets 00 to 7F (7 bit US-ASCII values)." > > http://www.faqs.org/rfcs/rfc3629.html Well, I realize 0x00 is a valid ASCII value and therefore a valid UTF8 value but we have never had anyone complain they can't store the 0x00 character because it doesn't mean anything in ASCII. They use bytea to store binary data like 0x00. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3819: UTF8 can't handle \000
On Dec 17, 2007 12:54 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > Uh, as far as I know 0x00 is not a valid UTF8 byte value. I think it is a valid value. RFC 3629 says: "Character numbers from U+ to U+007F (US-ASCII repertoire) correspond to octets 00 to 7F (7 bit US-ASCII values)." http://www.faqs.org/rfcs/rfc3629.html ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3819: UTF8 can't handle \000
On Dec 17, 2007 1:28 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > Well, I realize 0x00 is a valid ASCII value and therefore a valid UTF8 > value but we have never had anyone complain they can't store the 0x00 > character because it doesn't mean anything in ASCII. They use bytea to > store binary data like 0x00. Here are a few complaints: http://www.nabble.com/-tp9058998.html http://www.nabble.com/-tp11750041.html http://www.nabble.com/-tp8414157.html I agree that storing 0x00 in a UTF8 string is weird, but I am converting a huge database to postgres, and in a huge database, weird things happen. Using bytea for a text field just because one in a million records has a 0x00 doesn't make sense to me. I did hack around it in my conversion code to remove the 0x00 but I expect that anyone else who tries converting a big database to postgres will also confront this issue. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #3821: Wrong language at "Installation Notes"
The following bug has been logged online: Bug reference: 3821 Logged by: Ronny Hellgren Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: Windows XP Description:Wrong language at "Installation Notes" Details: When I am trying to install PostgreSQL 8.2, you can chose which language the installation will be showed in. If you chose "Swedish", the page for "Installation Notes" will be in Turkish(!), not in Swedish !! And I am not that good in turkish... ;-) Hope you will change this in the future ! Regards Ronny Hellgren ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #3819: UTF8 can't handle \000
Franklin Schmidt wrote: I agree that storing 0x00 in a UTF8 string is weird, but I am converting a huge database to postgres, and in a huge database, weird things happen. Using bytea for a text field just because one in a million records has a 0x00 doesn't make sense to me. I did hack around it in my conversion code to remove the 0x00 but I expect that anyone else who tries converting a big database to postgres will also confront this issue. That's the right solution. If you have 0x00 bytes in your text fields, you're much better off cleaning them away anyway, than trying to work around them. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] bug found in 8.3 beta 3.
Hi, I found this bug? In beta 3. I am not a Linux guru so installing any betas in Debian is very painful for me. Perhaps you could check to see if it is still there in beta 4?? Last time I reported a bug http://archives.postgresql.org/pgsql-committers/2007-11/msg00584.php I did not get any direct feedback and only found it by fluke. My pgsql-bugs subscription is set to "nomail". Please reply directly to [EMAIL PROTECTED] Here are the steps that demonstrate the problem: drop type t_tempbug_c cascade; create type t_tempbug_c as ( CONF_KEY int4 ) ; create or replace function tempbug_c() returns SETOF t_tempbug_c as $$ declare begin drop table if exists temp_table cascade; create temporary table temp_table(a int); insert into temp_call_table values (7) ; return query select 0 from temp_call_table limit 1 ; end; $$ language plpgsql; create or replace function tempbug() returns SETOF t_tempbug_c as $$ declare val int; begin create temporary table temp_call_table (a int); perform tempbug_c() ; return query select * from temp_call_table ; drop table temp_call_table ; end; $$ language plpgsql; protocal2=> select * from tempbug() ; ERROR: set-valued function called in context that cannot accept a set CONTEXT: PL/pgSQL function "tempbug_c" line 6 at RETURN QUERY SQL statement "SELECT tempbug_c()" PL/pgSQL function "tempbug" line 5 at PERFORM protocal2=> select version() ; version - PostgreSQL 8.3beta3 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3 20071014 (prerelease) (Debian 4.2.2-3) (1 row)
Re: [BUGS] bug found in 8.3 beta 3.
"chris wood" <[EMAIL PROTECTED]> writes: > Hi, I found this bug? In beta 3. I am not a Linux guru so installing any > betas in Debian is very painful for me. Perhaps you could check to see if > it is still there in beta 4?? I see no bug here. You're invoking a set-returning function from a PERFORM, which is a scalar context (it's not different from SELECT really). If you make the PERFORM be perform * from tempbug_c() ; then it doesn't complain. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[BUGS] BUG #3822: Nonstandard precedence for comparison operators
The following bug has been logged online:
Bug reference: 3822
Logged by: Pedro Gimeno
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5
Operating system: Any
Description:Nonstandard precedence for comparison operators
Details:
The operators <>, <= and >= are expected to have the same precedence as =, <
and >, but according to the docs (and matching actual behaviour) they have
the same precedence as e.g. ||.
This leads to surprises such as this one:
SELECT 'a' = 'b' || 'c';
SELECT 'a' < 'b' || 'c';
SELECT 'a' > 'b' || 'c';
return either FALSE or TRUE, but
SELECT 'a' <> 'b' || 'c';
SELECT 'a' <= 'b' || 'c';
SELECT 'a' >= 'b' || 'c';
give an error because they are equivalent to:
SELECT ('a' <> 'b') || 'c';
SELECT ('a' <= 'b') || 'c';
SELECT ('a' >= 'b') || 'c';
respectively, which try to concatenate a boolean value with 'c'. On the
other hand, the following work as expected:
SELECT 'b' || 'c' <> 'a';
SELECT 'b' || 'c' >= 'a';
SELECT 'b' || 'c' <= 'a';
That's because, having || and e.g. <> the same priority, they are evaluated
left-to-right.
Of course the same applies to != since it is converted to <>.
Now being picky, the precedence of < and > should be the same as that of =
(for comparison, not for assignment), which makes a difference in rare cases
like this:
SELECT false = false < false;
which in PostgreSQL returns true instead of false because it is equivalent
to this:
SELECT false = (false < false);
-- Pedro Gimeno
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] bug found in 8.3 beta 3.
Hi, Le Monday 17 December 2007 19:05:36 chris wood, vous avez écrit : > Hi, I found this bug? In beta 3. I am not a Linux guru so installing any > betas in Debian is very painful for me. Perhaps you could check to see if > it is still there in beta 4?? The experimental sources of debian already provides postgresql-8.3 beta4, so installing it is as easy as adding experimental to your testing server sources.list, or if you want to take no risk of upgrading other experimental packages, adding the deb-src experimental source and backporting: apt-get update apt-get build-dep postgresql-common postgresql-client-common postgresql-8.3 apt-get source -b postgresql-common postgresql-client-common postgresql-8.3 dpkg -i ... http://packages.debian.org/postgresql-8.3 Install at least the -common packages, libpq and the wanted components. Those -common packages contain the infamous debian wrappers which makes debian differs from other PostgreSQL installations, but allows to easily use several version at a time, including binary choice without messing with PATH manually (adding --cluster 8.3/main to "official" options --- version/clustername). Please note that 8.3b2 to 8.3b4 needs an initdb, and the debian packaging has no support for beta to beta upgrading. You'll certainly want to do it manually: pg_dumpall > backup.file apt-get remove postgresql-8.3 rm -rf $PGDATA/* (defaults to /var/lib/postgresql/8.3/main) psql -f backup.file Hope this helps, -- dim signature.asc Description: This is a digitally signed message part.
