[BUGS] BUG #4021: UUID NULL and not equal query failed
The following bug has been logged online: Bug reference: 4021 Logged by: Yann ROBIN Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.0 build 140 Operating system: Windows XP SP2 Description:UUID NULL and not equal query failed Details: Hi, I've tried to do a not like query on a UUID field and the row that i'd like to get has a NULL value for the UUID field, it gives me no result. The request : SELECT * FROM t_account WHERE Update_Timestamp '2008-03-09 12:35:10.309000' AND Update_Timestamp = '2008-03-09 12:35:37.861000' AND Update_Id != '48012851-3aa4-9940-9ab4-b8333da6b45b' 0 result. The same request without the Update_Id condition : SELECT * FROM t_account WHERE Update_Timestamp '2008-03-09 12:35:10.309000' AND Update_Timestamp = '2008-03-09 12:35:37.861000' 1 result. The Update_Id field is null. The same request but with a OR IS NULL condition : SELECT * FROM t_account WHERE Update_Timestamp '2008-03-09 12:35:10.309000' AND Update_Timestamp = '2008-03-09 12:35:37.861000' AND (Update_Id != '48012851-3aa4-9940-9ab4-b8333da6b45b' OR Update_Id IS NULL) 1 result. So my conclusion is that the NOT EQUAL operator doesn't match how it should the NULL value field. Is it a bug or a wanted behavior ? -- Yann -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #3986: Error ts_vector with UTF8 WS2003
-Message d'origine-
It seems to be a client encoding problem. What is your client_encoding?
A common problem is a mismatch between client_encoding and the terminal
or application encoding.
I've tried different encoding, I always get the same error.
As I said, I've got the same exact database on a windows XP and with the
same exact client, it works.
I found a workaround, when I use the to_tsvector function, I now specify the
configuration :
to_tsvector('test') = Error 22021
to_tsvector('simple', 'test') = OK
I think there a problem with the default behavior.
--
Yann
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4021: UUID NULL and not equal query failed
Yann ROBIN wrote: So my conclusion is that the NOT EQUAL operator doesn't match how it should the NULL value field. Is it a bug or a wanted behavior ? It's normal behavior, required by SQL standard, and not specific to UUIDs. See also http://www.postgresql.org/docs/8.3/interactive/functions-comparison.html. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4021: UUID NULL and not equal query failed
Thank you, you're right and I should have none ! -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Heikki Linnakangas Envoyé : dimanche 9 mars 2008 15:24 À : Yann ROBIN Cc : pgsql-bugs@postgresql.org Objet : Re: [BUGS] BUG #4021: UUID NULL and not equal query failed Yann ROBIN wrote: So my conclusion is that the NOT EQUAL operator doesn't match how it should the NULL value field. Is it a bug or a wanted behavior ? It's normal behavior, required by SQL standard, and not specific to UUIDs. See also http://www.postgresql.org/docs/8.3/interactive/functions-comparison.html. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] setseed accepts bad seeds
Kris Jurka [EMAIL PROTECTED] writes: On Wed, 11 Apr 2007, Tom Lane wrote: It's not really possible to use it incorrectly, AFAICS. Any value you might pass to it will result in a specific new seed value. Nowhere is there any guarantee of what the mapping is, and it's obviously impossible to guarantee that the mapping is one-to-one, so any user assumptions about what a specific seed value might mean seem broken regardless. Then please consider this patch which checks the range and maps the provided value to the entire seed space. I'm still not very happy about this. It'll change the behavior of existing applications, in the service of no goal that I consider convincing. I'd be inclined to leave the mapping alone and just insert a warning (or hard error) for inputs outside the range -1 to 1. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
