[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 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 fire. It's a side effect of how the spec defines operations on nulls. ---(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] Bug #611: configure script produces incorrect results under IRIX
Jonathan C. Patschke ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description configure script produces incorrect results under IRIX Long Description Under IRIX (and, presumably, other commercial UNIX platforms), the configure script in the root of the source distribution causes a number of tests to fail, where they should pass. Some of these tests (detecting the presence of vsnprintf() and snprintf() in the system headers, for example) must pass for the resulting code to compile with MIPSpro C. The root cause of this problem is that the script interpreter for the configure script is /bin/sh. The configure script is NOT a /bin/sh compatible script. It requires GNU BASH to execute properly. This may, in all actuality, be an autoconf bug or an IRIX /bin/sh bug, but it hindered my using PostgreSQL. WORKAROUND: Edit the configure script to run under /usr/freeware/bin/bash, rather than /bin/sh. Or call the script as "bash configure [options]" SUGGESTED SOLUTION: Since not everyone installs bash in the same location. the configure script should test its interpreter and throw an error if not running inside BASH. Sample Code Inserting the following code into the configure script will produce the effect I recommended above. I placed the code just before the line reading "# Defaults:", and it worked well for me; however, putting it -after- the help generation code exits might be more fruitful. I'm not an autoconf guru, so I wouldn't know where to put the code in configure.in. ## Begin sample code if [ "" = "$BASH_VERSION" ] ; then echo '*** ERROR: Not running in BASH ***' echo '' echo "The PostgreSQL configure script requires the GNU BASH" echo "command interpreter. If you do not have a copy of BASH," echo "you may obtain one at the following URL:" echo '' echo " http://www.gnu.org/software/bash/bash.html"; echo '' echo "If BASH is already installed on your system, please execute" echo "the configure script in the following manner:" echo '' echo ' bash configure [options]' echo '' exit 1; fi ## End sample code No file was uploaded with this report ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
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] Bug #612: PostgreSQL 7.2 does not build according to documentation under IRIX w/ MIPSpro
Jonathan C. Patschke ([EMAIL PROTECTED]) reports a bug with a severity of 1 The lower the number the more severe it is. Short Description PostgreSQL 7.2 does not build according to documentation under IRIX w/ MIPSpro Long Description Ignore my submission about sh-vs-bash in configure. Configure is still broken (doesn't set HAVE_SNPRINTF_DECL properly), and the resulting tree still doesn't build under IRIX with MIPSpro ($CC accidentally got reset to gcc between tries). Should any of the developers desire an IRIX build-box, email me, and I'll see what I can do to make my system available. Here's my environment: [jp@firehawk:/usr/src/postgresql-7.2]$ echo $BASH_VERSION -- $CC -- $CXX 2.05.0(1)-release -- /usr/bin/cc -- /usr/bin/CC [jp@firehawk:/usr/src/postgresql-7.2]$ cc -version MIPSpro Compilers: Version 7.3.1.2m [jp@firehawk:/usr/src/postgresql-7.2]$ CC -version MIPSpro Compilers: Version 7.3.1.2m [jp@firehawk:/usr/src/postgresql-7.2]$ gmake --version GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for mips-sgi-irix6.5 Here is the output of a configure + build run on a virgin source tree: [jp@firehawk:/usr/src/postgresql-7.2]$ bash configure --prefix=/usr/db/postgres --with-includes=/usr/freeware/include --with-libs=/usr/freeware/lib --with-tcl --with-tclconfig=/usr/freeware/lib --with-tkconfig=/usr/freeware/lib --with-perl --with-openssl=/usr/freeware/ssl --enable-syslog > build.out 2>&1 ; gmake >> build.out 2>&1 creating cache ./config.cache checking host system type... mips-sgi-irix6.5 checking which template to use... irix5 checking whether to build with locale support... no checking whether to build with recode support... no checking whether to build with multibyte character support... no checking whether NLS is wanted... no checking for default port number... 5432 checking for default soft limit on number of connections... 32 checking for gcc... /usr/bin/cc checking whether the C compiler (/usr/bin/cc -O3 -I/usr/freeware/include -L/usr/freeware/lib32 -L/usr/lib32) works... yes checking whether the C compiler (/usr/bin/cc -O3 -I/usr/freeware/include -L/usr/freeware/lib32 -L/usr/lib32) is a cross-compiler... no checking whether we are using GNU C... no checking whether /usr/bin/cc accepts -g... yes using CFLAGS=-O3 -I/usr/freeware/include checking whether the C compiler (/usr/bin/cc -O3 -I/usr/freeware/include -L/usr/freeware/lib32 -L/usr/lib32) works... yes checking whether the C compiler (/usr/bin/cc -O3 -I/usr/freeware/include -L/usr/freeware/lib32 -L/usr/lib32) is a cross-compiler... no checking for Cygwin environment... no checking for mingw32 environment... no checking for executable suffix... no checking how to run the C preprocessor... /lib/cpp checking whether to build with Tcl... yes checking whether to build with Tk... yes checking whether to build Perl modules... yes checking whether to build Python modules... no checking whether to build Java/JDBC tools... no checking whether to build with PAM support... no building with OpenSSL support checking whether to build the ODBC driver... no checking whether to build C++ modules... no using CPPFLAGS= -I/usr/freeware/include using LDFLAGS=-L/usr/freeware/lib32 -L/usr/lib32 -L/usr/freeware/lib -L/usr/freeware/ssl/lib checking for mawk... no checking for gawk... gawk checking for flex... /usr/freeware/bin/flex checking whether ln -s works... yes checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for ranlib... ranlib checking for lorder... no checking for tar... /usr/freeware/bin/tar checking for bison... bison -y checking for wish... /usr/freeware/bin/wish checking for perl... /usr/freeware/bin/perl checking Perl installation directories... done checking for readline... yes (-lreadline -ltermcap) checking for library containing using_history... none required checking for main in -lbsd... yes checking for setproctitle in -lutil... no checking for main in -lm... yes checking for main in -ldl... yes checking for main in -lsocket... yes checking for main in -lnsl... yes checking for main in -lipc... no checking for main in -lIPC... no checking for main in -llc... no checking for main in -ldld... no checking for main in -lld... no checking for main in -lcompat... no checking for main in -lBSD... no checking for main in -lgen... yes checking for main in -lPW... yes checking for main in -lresolv... no checking for main in -lunix... no checking for library containing crypt... none required checking for __inet_ntoa in -lbind... no checking for inflate in -lz... yes checking for library containing fdatasync... none required checking for CRYPTO_new_ex_data in -lcrypto... yes checking for SSL_library_init in -lssl... yes checking for crypt.h... yes checking for dld.h... no checking for endian.h... no checking for fp_class.h... yes checking for getopt.h... yes checking for ieeefp.h... yes checking for pwd.h... yes checking for sys/ipc.h... yes checking for sys/pst
Re: [BUGS] comparing null value in plpgsql.
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. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
