[BUGS] comparing null value in plpgsql.
hi, here i have a problem in comparing null values in plpgsql. this exist in 7.1.x and 7.2 as well. the condition != fails in plpgsql. consider this function is triggered on every updation on a table. create function ftest() returns opaque as 'declare begin if new.comp_code != old.comp_code then ... end if; return new; end;' language 'plpgsql'; this condition fails if old.comp_code is null and new.comp_code has some value. to overcome this, i am practicing.. create function ftest() returns opaque as 'declare begin if new.comp_code is not null and old.comp_code is null then ... else if new.comp_code != old.comp_code then ... end if; end if; return new; end;' language 'plpgsql'; is it really a bug or i am wrong? let me know. if its a bug, when can we expect the fix? kindly apologize if it has been already discussed. Regards, Bhuvaneswaran. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] comparing null value in plpgsql.
On Mar 10, Stephan Szabo wrote: > On Mon, 11 Mar 2002, Bhuvan A wrote: > > > here i have a problem in comparing null values in plpgsql. this exist > > in 7.1.x and 7.2 as well. > > > > the condition != fails in plpgsql. > > consider this function is triggered on every updation on a table. > > > > create function ftest() > > returns opaque as 'declare > > > > begin > > > > if new.comp_code != old.comp_code then > > ... > > end if; > > return new; > > end;' > > language 'plpgsql'; > > > > this condition fails if old.comp_code is null and new.comp_code has > > some value. > > != is not true, it's unknown, so the if shouldn't what do you mean by != ? > fire. It's a side effect of how the spec defines operations on nulls. > here i mean.. if != , the loop is not fired, but else loop is getting fired. why? Regards, Bhuvaneswaran. ---(end of broadcast)--- TIP 3: 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]
On Mar 11, Stephan Szabo wrote: > > On Mon, 11 Mar 2002, Bhuvan A wrote: > > > > > > > On Mar 10, Stephan Szabo wrote: > > > > > On Mon, 11 Mar 2002, Bhuvan A wrote: > > > > > > > here i have a problem in comparing null values in plpgsql. this exist > > > > in 7.1.x and 7.2 as well. > > > > > > > > the condition != fails in plpgsql. > > > > consider this function is triggered on every updation on a table. > > > > > > > > create function ftest() > > > > returns opaque as 'declare > > > > > > > > begin > > > > > > > > if new.comp_code != old.comp_code then > > > > ... > > > > end if; > > > > return new; > > > > end;' > > > > language 'plpgsql'; > > > > > > > > this condition fails if old.comp_code is null and new.comp_code has > > > > some value. > > > > > > != is not true, it's unknown, so the if shouldn't > > > > what do you mean by != ? > > If you compare a NULL with anything you don't get a true value whether > you're comparing with =, !=, <, >, etc... That's how it's defined to > behave. where did you get this definition of behaviour!? is it applicable only to postgres or ..? its quite strange yaar! > ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] sequence havn't been dropped.
hi, Hope you might have came accross this problem earlier. it exists in 7.1.x and 7.2 as well. while creating a table with a column of type 'serial', well a sequence has been created and the default value of that field is set to nextval of that sequence, fine. But while dropping that table, why aren't that sequence dropped? example: bhuvandb=# CREATE TABLE seq_test (id serial, name text); NOTICE: CREATE TABLE will create implicit sequence 'seq_test_id_seq' for SERIAL column 'seq_test.id' NOTICE: CREATE TABLE/UNIQUE will create implicit index 'seq_test_id_key' for table 'seq_test' CREATE bhuvandb=# DROP TABLE seq_test ; DROP bhuvandb=# CREATE TABLE seq_test (id serial, name text); NOTICE: CREATE TABLE will create implicit sequence 'seq_test_id_seq' for SERIAL column 'seq_test.id' NOTICE: CREATE TABLE/UNIQUE will create implicit index 'seq_test_id_key' for table 'seq_test' ERROR: Relation 'seq_test_id_seq' already exists hope, developers would have their own reasons. but wish to know that. thats it. Regards, Bhuvaneswaran. ---(end of broadcast)--- TIP 3: 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] Casting integer to boolean
Hi, I am using postgresql 7.2.1. How do i cast an integer value to boolean? I did try the below sequence of SQLs and was little bit confused, by the way it behaves. It casts the integer value to boolean in one case but not ever again. bhuvan=> SELECT count(*)::int::boolean from my_table; ERROR: Cannot cast type 'integer' to 'boolean' bhuvan=> -- The SQL similar to the above SQL is my requirement bhuvan=> SELECT true where (1); ERROR: WHERE clause must return type boolean, not type integer bhuvan=> SELECT true where (1::boolean); bool -- t (1 row) bhuvan=> SELECT true where (1::int::boolean); ERROR: Cannot cast type 'integer' to 'boolean' bhuvan=> I donot know whether i am wrong or its a bug. I request someone to correct me if i am wrong or please suggest me the right way to cast an integer to boolean as, returning true for non-zero value, false otherwise. regards, bhuvaneswaran ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bug #804: plpgsql not work on solaris
> Long Description > I try to create language plpgsql for db "template1" on solaris 9 but don't work. > It's seems that all other work, but i' don't sure. > Below i write the response of shell (bash). > > Sample Code > bash-2.05$ createlang plpgsql template1 > ERROR: Load of file /usr/local/pgsql/lib/plpgsql.so failed: ld.so.1: >/usr/local/pgsql/bin/postmaster: errore fatale:libgcc_s.so.1: impossibile aprire: >File o directory non trovati > createlang: language installation failed I suppose, the language interpreter is not in that directory. Try $ locate plpgsql.so /usr/lib/pgsql/plpgsql.ro $ createlang -L /usr/lib/pgsql/ -d template1 'plpgsql' regards, bhuvaneswaran ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Bug #880: COMMENT ON DATABASE depends on current database
> Long Description PostgreSQL has mechanism for commenting databases. > Database comments can by read by obj_description(oid), psql \l+ command > use it. Database comments should be global, but they are not, when we do > \l+ on one database, and then on other, results will be different. I > consider it is a bug, database is global object (You can connect to it > from any database) but their comments are not. > I too consider it as a bug. But why no response? I hope someone is hearing. regards, bhuvaneswaran ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
