Re: Comparing bug in 4.1.7
Arjen Lentz wrote: [...] While we're at it: the term "non-zero"... what does it mean? As we all know, NULL != 0, and 0 == zero, consequently NULL must be non-zero. Flawed logic. Yes, I used flawed logic to illustrate my point: "non-zero" is a bad term to use in this context. The text from the documentation that we were discussing, has been changed in the online docs after this discussion. While the term "non-zero" is still used, the special cases with NULL operands are described, making the current text harder to misinterpret. [...] If I'm not mistaken, ALL combinations are now tested in the standard test suite so any bug would block a release going out. Sounds good. :) -- Roger -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Comparing bug in 4.1.7
Hi Roger, Michael, Vlad, Let me just follow up on this old thread, as it may clarify some things. On Fri, 2004-12-03 at 02:00, Roger Baklund wrote: > Michael Stassen wrote: > > You are overthinking the issue. > > Probably. :) > > > mysql> SELECT VERSION(); > > +---+ > > | VERSION() | > > +---+ > > | 4.1.7 | > > +---+ > > 1 row in set (0.00 sec) > > > > mysql> SELECT 1 OR NULL; > > +---+ > > | 1 OR NULL | > > +---+ > > | 1 | > > +---+ > > 1 row in set (0.00 sec) > > > > We do not need to know x to determine that 1 OR x is TRUE (1). That is > > the nature of OR - it only takes one TRUE value to result in TRUE (1). > > I agree. Oh, boolean logic in SQL has some funny stuff if you look at the truth tables. However TRUE OR NULL does equal TRUE according to the SQL standard. So MySQL's implementation is correct, as shown above. > > Hence, 1 or NULL must evaluate to TRUE (1). This is a case where we > > should correct the definition in the manual, rather than redefining how > > OR should behave based on the the manual's poor choice of wording. > > I agree. > > > Therefore, Vlad has found a bug: > > I agree again. :) > > This is (as I see it) a documentation issue, I was not trying to say > that Vlad was "wrong". The manual does show this example: mysql> SELECT 1 || NULL; -> 1 > >> While we're at it: the term "non-zero"... what does it mean? As we all > >> know, NULL != 0, and 0 == zero, consequently NULL must be non-zero. Flawed logic. Remember Venn diagrams from highschool? The circles with numbers in them, circles can overlap, etc... the realm of valid data of a type is enclosed in a circle, like 0-255 for a TINYINT. NULL is not part of that set, it falls outside the realm. You can't make any ordinary comparison with NULL, and that's also why SQL ended up having some funny logic where logical operations that include NULLs (like the above) sometimes appear to have odd answers. However, MySQL is doing it correctly (as per the standard). There used to be a bug in the handling of AND, due to an optimization in some specific cases, but this was fixed ages ago in a 4.0 release. If I'm not mistaken, ALL combinations are now tested in the standard test suite so any bug would block a release going out. > I would like to have a comment on this as well... or rather: I wonder if > anyone agrees with me that "non-zero" is a bad term to use in this > context (MySQL documentation, description of logical operator OR), or if > I am just overthinking again... :) You are right. NULL is not a non-zero value. NULL is not a value at all. Regards, Arjen. -- Arjen Lentz, Community Relations Manager MySQL AB, www.mysql.com MySQL Users Conference (Santa Clara CA, 18-21 April 2005) Early registration until February 28: http://www.mysqluc.com/ 22 days left for early registration, 70 days until the event! -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Comparing bug in 4.1.7
Hi Vlad ! Why not using select (select min( a ) is null from a) or null; as a workaround ? Regards, Jocelyn - Original Message - From: "Vlad Shalnev" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, December 03, 2004 7:01 AM Subject: Re: Comparing bug in 4.1.7 > > > Sergei Golubchik wrote: > > Hi! > > > > On Dec 02, Vlad Shalnev wrote: > > > > Looks like a bug. > > Could you submit a bugreport at http://bugs.mysql.com ? > > > > I've submitted a bugreport. > > Downgrade to 3.23 and wait for this problem solving. > > Thanks for all > > > > >>It happens after upgrade from 3.23.46. > >> > >>mysql> create table a ( a int not null ); > >>Query OK, 0 rows affected (0.00 sec) > >> > >>mysql> select min( a ) is null or null from a; > >>+--+ > >>| min( a ) is null or null | > >>+--+ > >>| NULL | -> Why ??? > >>+--+ > >>1 row in set (0.00 sec) > >> > >>It is very important for me to solve this problem. Thanks for any help > > > > > > Regards, > > Sergei > > > > -- > -- -- > Vlad A. Shalnev > E-mail: [EMAIL PROTECTED] > > "Gravity can't be blamed > for someone > falling in love" > > ( Albert Einstein ) > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Comparing bug in 4.1.7
Sergei Golubchik wrote: Hi! On Dec 02, Vlad Shalnev wrote: Looks like a bug. Could you submit a bugreport at http://bugs.mysql.com ? I've submitted a bugreport. Downgrade to 3.23 and wait for this problem solving. Thanks for all It happens after upgrade from 3.23.46. mysql> create table a ( a int not null ); Query OK, 0 rows affected (0.00 sec) mysql> select min( a ) is null or null from a; +--+ | min( a ) is null or null | +--+ | NULL | -> Why ??? +--+ 1 row in set (0.00 sec) It is very important for me to solve this problem. Thanks for any help Regards, Sergei -- Vlad A. Shalnev E-mail: [EMAIL PROTECTED] "Gravity can't be blamed for someone falling in love" ( Albert Einstein ) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Comparing bug in 4.1.7
At 11:42 -0500 12/2/04, Michael Stassen wrote: Roger Baklund wrote: This is (as I see it) a documentation issue, I was not trying to say that Vlad was "wrong". Right, that's why I'm copying the docs list. I updated the description to account for the cases when there are 1 or 2 NULL operands. It should show up on the Web site soon. Basically, the idea is that if there is a NULL operand, OR returns true if the result can be determined to be true, and NULL otherwise. 1 OR NULL = 1 0 OR NULL = NULL NULL OR NULL = NULL While we're at it: the term "non-zero"... what does it mean? As we all know, NULL != 0, and 0 == zero, consequently NULL must be non-zero. I would like to have a comment on this as well... or rather: I wonder if anyone agrees with me that "non-zero" is a bad term to use in this context (MySQL documentation, description of logical operator OR), or if I am just overthinking again... :) Well, if we imagined a NONZERO function, I think we would agree that NONZERO(1) is 1, NONZERO(0) is 0, and NONZERO(NULL) is NULL (for the usual reasons). Of course, that doesn't mean that "non-zero" alone is the best way to describe this in the docs. Perhaps something like this would be better: OR || Logical OR. Returns 1 if either operand evaluates to a non-zero integer, else it returns NULL if either operand is NULL, otherwise 0 is returned. or perhaps OR || Logical OR. If either operand evaluates to a non-zero integer, returns 1; else if either operand is NULL, returns NULL; otherwise 0 is returned. Michael -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- Paul DuBois, MySQL Documentation Team Madison, Wisconsin, USA MySQL AB, www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Comparing bug in 4.1.7
I upgraded from 5.01 to 5.02 and now I am getting the error localhost is not allowed to connect to this MySQL server. What should I do, root cannot connect a well. I'm currently using win32 and have old-passwords in my.cnf Thanks -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Comparing bug in 4.1.7
Roger Baklund wrote: This is (as I see it) a documentation issue, I was not trying to say that Vlad was "wrong". Right, that's why I'm copying the docs list. While we're at it: the term "non-zero"... what does it mean? As we all know, NULL != 0, and 0 == zero, consequently NULL must be non-zero. I would like to have a comment on this as well... or rather: I wonder if anyone agrees with me that "non-zero" is a bad term to use in this context (MySQL documentation, description of logical operator OR), or if I am just overthinking again... :) Well, if we imagined a NONZERO function, I think we would agree that NONZERO(1) is 1, NONZERO(0) is 0, and NONZERO(NULL) is NULL (for the usual reasons). Of course, that doesn't mean that "non-zero" alone is the best way to describe this in the docs. Perhaps something like this would be better: OR || Logical OR. Returns 1 if either operand evaluates to a non-zero integer, else it returns NULL if either operand is NULL, otherwise 0 is returned. or perhaps OR || Logical OR. If either operand evaluates to a non-zero integer, returns 1; else if either operand is NULL, returns NULL; otherwise 0 is returned. Michael -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: Comparing bug in 4.1.7
> -Original Message-
> From: Roger Baklund [mailto:[EMAIL PROTECTED]
> This definition (from the manual) is self-contradicting: 1 OR NULL
> should evaluate to 1 because "any operand is non-zero", but it should
> also evaluate to NULL because "any operand is NULL".
>
> http://dev.mysql.com/doc/mysql/en/Logical_Operators.html >
>
> With an unclear definition, it is perhaps not so strange that
> behaviour will change with different versions of MySQL...?
I suspect the reason "1 OR NULL" returns 1 in some versions is that the OR
operator "short circuits", like in C. A "short circuit" operator is one
that stops executing code as soon as the result is clear. In the case of
OR, that means if you find one operand that's true, you don't have to check
the other operands. (OR also short-circuits in Perl, which is why
statements like 'do_something() or die("It didn't work!")' work as expected.
If do_something() returns true, the die() is never executed.)
What does the SQL standard say about this, if anything? I thought the
result of any operation on NULL was supposed to return NULL, but I could be
wrong.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Comparing bug in 4.1.7
Michael Stassen wrote: You are overthinking the issue. Probably. :) mysql> SELECT VERSION(); +---+ | VERSION() | +---+ | 4.1.7 | +---+ 1 row in set (0.00 sec) mysql> SELECT 1 OR NULL; +---+ | 1 OR NULL | +---+ | 1 | +---+ 1 row in set (0.00 sec) We do not need to know x to determine that 1 OR x is TRUE (1). That is the nature of OR - it only takes one TRUE value to result in TRUE (1). I agree. Hence, 1 or NULL must evaluate to TRUE (1). This is a case where we should correct the definition in the manual, rather than redefining how OR should behave based on the the manual's poor choice of wording. I agree. Therefore, Vlad has found a bug: I agree again. :) This is (as I see it) a documentation issue, I was not trying to say that Vlad was "wrong". While we're at it: the term "non-zero"... what does it mean? As we all know, NULL != 0, and 0 == zero, consequently NULL must be non-zero. I would like to have a comment on this as well... or rather: I wonder if anyone agrees with me that "non-zero" is a bad term to use in this context (MySQL documentation, description of logical operator OR), or if I am just overthinking again... :) -- Roger -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Comparing bug in 4.1.7
You are overthinking the issue. mysql> SELECT VERSION(); +---+ | VERSION() | +---+ | 4.1.7 | +---+ 1 row in set (0.00 sec) mysql> SELECT 1 OR NULL; +---+ | 1 OR NULL | +---+ | 1 | +---+ 1 row in set (0.00 sec) We do not need to know x to determine that 1 OR x is TRUE (1). That is the nature of OR - it only takes one TRUE value to result in TRUE (1). Hence, 1 or NULL must evaluate to TRUE (1). This is a case where we should correct the definition in the manual, rather than redefining how OR should behave based on the the manual's poor choice of wording. I have no doubt that the wording is a translation of the code. Something like: if either argument is 1 return 1, else if any argument is null return null, else return 0. Unfortunately, the "else"s are missing, leaving the progression implied rather than explicit. Therefore, Vlad has found a bug: mysql> CREATE TABLE nullbug (a INT NOT NULL); Query OK, 0 rows affected (0.01 sec) mysql> SELECT MIN(a), MIN(a) IS NULL, MIN(a) IS NULL OR NULL FROM nullbug; ++++ | MIN(a) | MIN(a) IS NULL | MIN(a) IS NULL OR NULL | ++++ | NULL | 1 | NULL | ++++ 1 row in set (0.00 sec) I expect an overly aggressive optimizer. Michael Roger Baklund wrote: Vlad Shalnev wrote: * from the manual: >> Logical OR. Evaluates to 1 if any operand is non-zero, to NULL if any >> operand is NULL, otherwise 0 is returned. * Roger Baklund: This definition (from the manual) is self-contradicting: 1 OR NULL should evaluate to 1 because "any operand is non-zero", but it should also evaluate to NULL because "any operand is NULL". Why self-contradicting ? It is self-contradicting because one part of the definition contradicts another part of the same definition. > If you apply this rule as described ( from left to right ) you will get correct result. Definitions are usually not implemented left to right. Consider this definition: "The day can be devided into two parts: at night it is dark, in the day you can breathe." Implemented from left to right, it gives the "correct" answer, but that does not make it a good definition, mostly because the second part does not only fit the "day", it also fits the "night". A good definition is clear and unambiguous. While we're at it: the term "non-zero"... what does it mean? As we all know, NULL != 0, and 0 == zero, consequently NULL must be non-zero. I guess "non-false" or simply "true" would be more correct, as NULL evaluates to false in a boolean expression. > And it isn't work in 4.1.7 :(( I don't know why the behaviour has changed. I suggest it is because the definition is unclear, but I don't know. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Comparing bug in 4.1.7
Vlad Shalnev wrote: * from the manual: >> Logical OR. Evaluates to 1 if any operand is non-zero, to NULL if any >> operand is NULL, otherwise 0 is returned. * Roger Baklund: This definition (from the manual) is self-contradicting: 1 OR NULL should evaluate to 1 because "any operand is non-zero", but it should also evaluate to NULL because "any operand is NULL". Why self-contradicting ? It is self-contradicting because one part of the definition contradicts another part of the same definition. > If you apply this rule as described ( from left to right ) you will get correct result. Definitions are usually not implemented left to right. Consider this definition: "The day can be devided into two parts: at night it is dark, in the day you can breathe." Implemented from left to right, it gives the "correct" answer, but that does not make it a good definition, mostly because the second part does not only fit the "day", it also fits the "night". A good definition is clear and unambiguous. While we're at it: the term "non-zero"... what does it mean? As we all know, NULL != 0, and 0 == zero, consequently NULL must be non-zero. I guess "non-false" or simply "true" would be more correct, as NULL evaluates to false in a boolean expression. > And it isn't work in 4.1.7 :(( I don't know why the behaviour has changed. I suggest it is because the definition is unclear, but I don't know. -- Roger -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Comparing bug in 4.1.7
Hi! On Dec 02, Vlad Shalnev wrote: Looks like a bug. Could you submit a bugreport at http://bugs.mysql.com ? > It happens after upgrade from 3.23.46. > > mysql> create table a ( a int not null ); > Query OK, 0 rows affected (0.00 sec) > > mysql> select min( a ) is null or null from a; > +--+ > | min( a ) is null or null | > +--+ > | NULL | -> Why ??? > +--+ > 1 row in set (0.00 sec) > > It is very important for me to solve this problem. Thanks for any help Regards, Sergei -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ / Sergei Golubchik <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Senior Software Developer /_/ /_/\_, /___/\___\_\___/ Osnabrueck, Germany <___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Comparing bug in 4.1.7
Vlad Shalnev wrote: [...] OR || Logical OR. Evaluates to 1 if any operand is non-zero, to NULL if any operand is NULL, otherwise 0 is returned. This definition (from the manual) is self-contradicting: 1 OR NULL should evaluate to 1 because "any operand is non-zero", but it should also evaluate to NULL because "any operand is NULL". http://dev.mysql.com/doc/mysql/en/Logical_Operators.html > With an unclear definition, it is perhaps not so strange that behaviour will change with different versions of MySQL...? Maybe if you explain why you depend on this behaviour someone can suggest a workaround or a different solution? -- Roger -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Comparing bug in 4.1.7
Bernard Clement wrote: Hello Vlad, The reason is: "If one or both arguments are NULL, the result of the comparison is NULL, except for the NULL-safe <=> equality comparison operator. Thereore, "or NULL" in your select statement will always returned NULL. You can find all the rules for comparaison at URL: http://dev.mysql.com/doc/mysql/en/Comparison_Operators.html Thanks for help but this is not my case. My case described in section "Logical Operators": OR || Logical OR. Evaluates to 1 if any operand is non-zero, to NULL if any operand is NULL, otherwise 0 is returned. mysql> SELECT 1 || 1; -> 1 mysql> SELECT 1 || 0; -> 1 mysql> SELECT 0 || 0; -> 0 mysql> SELECT 0 || NULL; -> NULL mysql> SELECT 1 || NULL; -> 1 Any help appreciated. Hi, All It's happen after upgrade from 3.23.46. Just look at this set of queries mysql> select 1 or null; +---+ | 1 or null | +---+ | 1 | -> Ok +---+ 1 row in set (0.00 sec) mysql> create table a ( a int not null ); Query OK, 0 rows affected (0.00 sec) mysql> select min( a ) is null from a; +--+ | min( a ) is null | +--+ |1 | -> Ok +--+ 1 row in set (0.00 sec) mysql> select min( a ) is null or null from a; +--+ | min( a ) is null or null | +--+ | NULL | -> Why ??? +--+ 1 row in set (0.00 sec) It is very important for me to solve this problem. Thanks for any help Info from mysqlbug script Server version 4.1.7 Protocol version10 Connection Localhost via UNIX socket UNIX socket /tmp/.mysql.sock Uptime: 23 hours 43 min 34 sec Threads: 2 Questions: 53 Slow queries: 0 Opens: 20 Flush tables: 1 Open tables: 6 Queries per second avg: 0.001 C compiler:2.95.3 C++ compiler: 2.95.3 >Environment: System: SunOS asv 5.8 Generic_108529-23 i86pc i386 i86pc Architecture: i86pc Some paths: /usr/local/bin/perl /usr/ccs/bin/make /opt/sfw/bin/gmake /opt/sfw/bin/gcc /usr/local/bin/cc GCC: Reading specs from /opt/sfw/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/specs gcc version 2.95.3 20010315 (release) Compilation info: CC='gcc' CFLAGS='' CXX='g++' CXXFLAGS='' LDFLAGS='' ASFLAGS='' LIBC: -rw-r--r-- 1 root bin 1608268 Jul 30 2003 /lib/libc.a lrwxrwxrwx 1 root root 11 Mar 3 2004 /lib/libc.so -> ./libc.so.1 -rwxr-xr-x 1 root bin 956112 Jul 30 2003 /lib/libc.so.1 -rw-r--r-- 1 root bin 1608268 Jul 30 2003 /usr/lib/libc.a lrwxrwxrwx 1 root root 11 Mar 3 2004 /usr/lib/libc.so -> ./libc.so.1 -rwxr-xr-x 1 root bin 956112 Jul 30 2003 /usr/lib/libc.so.1 Configure command: ./configure '--prefix=/usr/local/mysql-4.1.7' '--exec-prefix=/usr/local/mysql-4.1.7' '--libexecdir=/usr/local/mysql-4.1.7/bin' '--localstatedir=/main/MysqlDB' '--enable-thread-safe-client' '--with-unix-socket-path=/tmp/.mysql.sock' '--with-mysqld-user=mysql' '--without-debug' '--without-bench' '--with-charset=koi8r' Perl: This is perl, version 5.005_03 built for i86pc-solaris -- --- - Vlad A. Shalnev E-mail: [EMAIL PROTECTED] "Gravity can't be blamed for someone falling in love" ( Albert Einstein ) -- Vlad A. Shalnev E-mail: [EMAIL PROTECTED] "Gravity can't be blamed for someone falling in love" ( Albert Einstein ) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Comparing bug in 4.1.7
Hello Vlad, The reason is: "If one or both arguments are NULL, the result of the comparison is NULL, except for the NULL-safe <=> equality comparison operator. Thereore, "or NULL" in your select statement will always returned NULL. You can find all the rules for comparaison at URL: http://dev.mysql.com/doc/mysql/en/Comparison_Operators.html Regards, Bernard On Thursday 02 December 2004 06:48, Vlad Shalnev wrote: > Hi, All > > It's happen after upgrade from 3.23.46. > > Just look at this set of queries > > mysql> select 1 or null; > +---+ > > | 1 or null | > > +---+ > > | 1 | -> Ok > > +---+ > 1 row in set (0.00 sec) > > > mysql> create table a ( a int not null ); > Query OK, 0 rows affected (0.00 sec) > > mysql> select min( a ) is null from a; > +--+ > > | min( a ) is null | > > +--+ > > |1 | -> Ok > > +--+ > 1 row in set (0.00 sec) > > > mysql> select min( a ) is null or null from a; > +--+ > > | min( a ) is null or null | > > +--+ > > | NULL | -> Why ??? > > +--+ > 1 row in set (0.00 sec) > > It is very important for me to solve this problem. Thanks for any help > > Info from mysqlbug script > > Server version 4.1.7 > Protocol version10 > Connection Localhost via UNIX socket > UNIX socket /tmp/.mysql.sock > Uptime: 23 hours 43 min 34 sec > > Threads: 2 Questions: 53 Slow queries: 0 Opens: 20 Flush tables: 1 > Open tables: 6 Queries per second avg: 0.001 > > >C compiler:2.95.3 > >C++ compiler: 2.95.3 > > > >Environment: > > > System: SunOS asv 5.8 Generic_108529-23 i86pc i386 i86pc > Architecture: i86pc > > Some paths: /usr/local/bin/perl /usr/ccs/bin/make /opt/sfw/bin/gmake > /opt/sfw/bin/gcc /usr/local/bin/cc > GCC: Reading specs from > /opt/sfw/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/specs gcc version 2.95.3 > 20010315 (release) > Compilation info: CC='gcc' CFLAGS='' CXX='g++' CXXFLAGS='' LDFLAGS='' > ASFLAGS='' > LIBC: > -rw-r--r-- 1 root bin 1608268 Jul 30 2003 /lib/libc.a > lrwxrwxrwx 1 root root 11 Mar 3 2004 /lib/libc.so -> > ./libc.so.1 -rwxr-xr-x 1 root bin 956112 Jul 30 2003 > /lib/libc.so.1 -rw-r--r-- 1 root bin 1608268 Jul 30 2003 > /usr/lib/libc.a lrwxrwxrwx 1 root root 11 Mar 3 2004 > /usr/lib/libc.so -> ./libc.so.1 > -rwxr-xr-x 1 root bin 956112 Jul 30 2003 /usr/lib/libc.so.1 > Configure command: ./configure '--prefix=/usr/local/mysql-4.1.7' > '--exec-prefix=/usr/local/mysql-4.1.7' > '--libexecdir=/usr/local/mysql-4.1.7/bin' '--localstatedir=/main/MysqlDB' > '--enable-thread-safe-client' > '--with-unix-socket-path=/tmp/.mysql.sock' '--with-mysqld-user=mysql' > '--without-debug' '--without-bench' '--with-charset=koi8r' > Perl: This is perl, version 5.005_03 built for i86pc-solaris > > -- > --- >- Vlad A. Shalnev > E-mail: [EMAIL PROTECTED] > > "Gravity can't be blamed > for someone > falling in love" > > ( Albert Einstein ) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
