[
http://issues.apache.org/jira/browse/DERBY-7?page=comments#action_12378022 ]
Bernt M. Johnsen commented on DERBY-7:
--
Committed revision 400066.
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
>
[ http://issues.apache.org/jira/browse/DERBY-7?page=all ]
Bernt M. Johnsen closed DERBY-7:
Resolution: Fixed
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://issues.apache.org/jira
DERBY-7 and DERBY-903 was applied in the oposite order on 10.1
compared to trunk.
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://issues.apache.org/jira/browse/DERBY-7
> Project: Derby
> Type: Bug
> Compon
[ http://issues.apache.org/jira/browse/DERBY-7?page=all ]
Bernt M. Johnsen reopened DERBY-7:
--
Need to apply changes from DERBY-903 in 10.1 branch
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
>
On 5/4/06, Bernt M. Johnsen <[EMAIL PROTECTED]> wrote:
The net result from the two mentioned commits is as far a I can seethe diff below. Myrna: can you confirm?
Index: java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset.java===
on of resultset.java to use an encoding-safe
mechanism? "
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://issues.apache.org/jira/browse/DERBY-7
> Project: Derby
> Type: Bug
> Components: SQL
>
> However, the test resultset.java has since had some work done on it,
> and I'm specifically concerned that you may have missed the changes
> I worked on for DERBY-903, which were committed with revision 378337
> and 379643.
>
> This eliminates the use of the constructor 'new String(bytes[]),
> w
Myrna van Lunteren (JIRA) wrote (2006-05-04 17:47:27):
> [
> http://issues.apache.org/jira/browse/DERBY-7?page=comments#action_12377852 ]
>
> Myrna van Lunteren commented on DERBY-7:
>
>
> Hi Berndt,
>
> I happened to spot the following
se an
encoding-safe mechanism?
Just compare with the current 10.2 resultset.java...
Thx,
Myrna
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://issues.apache.org/jira/browse/DERBY-7
> Project: Derby
> Type: Bug
>
[ http://issues.apache.org/jira/browse/DERBY-7?page=all ]
Bernt M. Johnsen closed DERBY-7:
Fix Version: 10.1.3.0
(was: 10.2.0.0)
Resolution: Fixed
Committed revision 399657 on 10.1 branch
> Bug in NULLIF Funct
[ http://issues.apache.org/jira/browse/DERBY-7?page=all ]
Bernt M. Johnsen reopened DERBY-7:
--
Merge to 10.1 branch
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://issues.apache.org/ji
[ http://issues.apache.org/jira/browse/DERBY-7?page=all ]
Bernt M. Johnsen closed DERBY-7:
Fix Version: 10.2.0.0
Resolution: Fixed
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
>
[ http://issues.apache.org/jira/browse/DERBY-7?page=all ]
Bernt M. Johnsen reopened DERBY-7:
--
Ooops lost the fixed 10.2
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://issues.
nding issues are left on it, so I am marking this as closed.
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://issues.apache.org/jira/browse/DERBY-7
> Project: Derby
> Type: Bug
> Components: SQL
> V
other (potential) problems
are mentioned.
Could someone with more knowledge about this field confirm that this issue is
fixed and that no more work is to be done on it?
If true, please close the issue.
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
>
42X89: Types 'CHAR' and
'INTEGER' are not type compatible. (Neither type
is assignable to the other type.)"
Environment:
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://issues.apache.org/
[ http://issues.apache.org/jira/browse/DERBY-7?page=all ]
Mamta A. Satoor resolved DERBY-7:
-
Resolution: Fixed
The build.xml change didn't belong to this patch as Satheesh guessed. Thanks
for catching it.
> Bug in NULLIF
ed to this bug, so I didn't submit
that change.
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://issues.apache.org/jira/browse/DERBY-7
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10
[ http://issues.apache.org/jira/browse/DERBY-7?page=all ]
Mamta A. Satoor reassigned DERBY-7:
---
Assign To: Mamta A. Satoor
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://issues.apache.
unchanged since the last patch and the changes are also the
same as the last patch.
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://issues.apache.org/jira/browse/DERBY-7
> Project: Derby
> Type: Bug
> Compon
[ http://issues.apache.org/jira/browse/DERBY-7?page=all ]
updated DERBY-7:
-
Attachment: derby7Nullif080205svndiff.txt
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://issues.apache.org/jira
Hi,
Just got back from 3-weeks vacation and I see that patch for Derby-7 NULLIF function is still waiting to be committed/reviewed for a long time now. I was wondering if someone can take a look and see if it is all ready to be committed.
thanks,
Mamta
On 6/12/05, Mamta Satoor <[EMAIL PROTECT
Hi,
I have attached a patch in JIRA to Derby-7 to fix the NULLIF problem. The test suites have run fine with the exception of miserrors. Since the time I posted the patch, I saw subsequent emails about miscerror failure possibly related to checkin from David Van Couvering. David I think has alrea
[ http://issues.apache.org/jira/browse/DERBY-7?page=all ]
Mamta A. Satoor updated DERBY-7:
Attachment: Derby7NullIf061005svndiff.txt
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://is
ests\master\DerbyNet\resultset.out
M
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\resultset.out
M java\testing\org\apache\derbyTesting\functionTests\master\resultset.out
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
>
this is
right, but at least it will be consistent. It might be worth exploring if
COALESCE can be implemented as a large CASE statement.
It also reuses the SQLState codes for a couple of errors as I am not sure of
the policy for changing the associated text or adding new ones.
> Bug in NUL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Amit Handa (JIRA) wrote:
> > The conclusion is that the expression
> > CASE WHEN ... THEN intValue ELSE charValue END
> > is non-conforming SQL and may be processed in an
implementation-dependent manner.
>
> I hope this clears your doubts.
Not mi
E charValue END
is non-conforming SQL and may be processed in an implementation-dependent
manner.
Bug in NULLIF Function
--
Key: DERBY-7
URL: http://issues.apache.org/jira/browse/DERBY-7
Project: Derby
Type: Bug
Components: SQL
Versions: 10.0.2.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Amit Handa (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-7?page=history ]
>
> Amit Handa updated DERBY-7:
> ---
>
> Attachment: Derby-7.txt
>
> Submitting Patch as per discussion.
I have concerns simila
ules is implementation-dependent. ..."
The conclusion is that the expression
CASE WHEN ... THEN intValue ELSE charValue END
is non-conforming SQL and may be processed in an implementation-dependent
manner.
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
6
I think it shouldn't. I have a feeling we are not confirming to SQL standard
(ISO/IEC 9075-2:2003) 9.3 section, 'Data types of results of aggregations' here.
Satheesh
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
>
[ http://issues.apache.org/jira/browse/DERBY-7?page=history ]
Amit Handa updated DERBY-7:
---
Attachment: Derby-7.txt
Submitting Patch as per discussion.
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
>
;INTEGER' are not supported.
I believe though that this is a separate issue affecting all comparisons.
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://nagoya.apache.org/jira/browse/DERBY-7
> Project: Derby
>
uilt-in broadening conversion must exist" should
be extended and the data type of the result should be documented.
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://nagoya.apache.org/jira/browse/DERBY-7
> Project: Derby
&
1 and 2 work with the fix, rest all fail.
So kindly let me know if you guys approve the fix.
If not, kindly update what is missing which needs to be fixed or is not being
fixed with the patch proposed.
Please do vote in favour or against with some justification.
> Bug in NULLIF Functio
RPost wrote:
The discussion now seems to involve comparisons between 'char' and 'int'.
Please clarify what result Derby should provide for these examples:
1. nullif('a','b');
'a' with type CHAR(1)
2. nullif(1,2);
1 with type INTEGER
3. nullif('a', 1);
error as 'a' is not a valid numeric
4.
rse the type of NULL is fairly
meaningless but it would have an impact if we were referencing columns instead.
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://nagoya.apache.org/jira/browse/DERBY-7
> Project: Derby
>
values (case when 1.0=1.0 then cast(null as int) else 10 end);
For NULLIF() this is not possible.
Bug in NULLIF Function
--
Key: DERBY-7
URL: http://nagoya.apache.org/jira/browse/DERBY-7
Project: Derby
Type: Bug
Components: SQL
using CONDITIONAL_NODE.
But for CASE, the error can be avoided by using "CAST(NULL as INT)" instead of
an untyped NULL:
values (case when 1.0=1.0 then cast(null as int) else 10 end);
For NULLIF() this is not possible.
> Bug in NULLIF Function
> --
>
> Key: D
I think issues here may be slightly different...
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://nagoya.apache.org/jira/browse/DERBY-7
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.0.2
- Original Message -----
From: "Christian d'Heureuse (JIRA)"
To:
Sent: Monday, December 27, 2004 7:07 AM
Subject: [jira] Commented: (DERBY-7) Bug in NULLIF Function
> [
http://nagoya.apache.org/jira/browse/DERBY-7?page=comments#action_57072 ]
>
> C
BIT, VARBIT, BIT, BOOLEAN, TIME, TIMESTAMP, DATE,
DOUBLE, REAL, DECIMAL, NUMERIC, LONGINT, INT, SMALLINT, TINYINT, REF,
NATIONAL_LONGVARCHAR, NATIONAL_VARCHAR, NATIONAL_CHAR, CLOB, NCLOB,
LONGVARCHAR, VARCHAR, CHAR.
For DECIMAL/NUMERIC types, scale and precision are broadened to matche both
input
o solve this problem, the data type of L (leftExpression) could be used to
>build the NULL >constant node, instead of CHAR(1).
That is what is happenning, I hope the above helps in clarifying that
else I can explain that using code from ConditionalNode.bindExpression()
> Bug in NULL
[ http://nagoya.apache.org/jira/browse/DERBY-7?page=comments#action_57001 ]
Amit Handa commented on DERBY-7:
I don't think so I have seen anything on issues with Nullif on the mailing
lists.
Can you elaborate more on what are the issues ?
>
is incorrect. If I
remember right, that caused other issues.
Since there has been some interest in fixing this defect, I can volunteer to
look at possible fix. Christian suggestion seems to be in the right direction,
but I need to do more research.
> Bug in NULLIF Funct
R and INT are not compatible.
To solve this problem, the data type of L (leftExpression) could be used to
build the NULL constant node, instead of CHAR(1).
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://nagoya.apache.or
[ http://nagoya.apache.org/jira/browse/DERBY-7?page=comments#action_56969 ]
Christian d'Heureuse commented on DERBY-7:
--
> nullif(cast(null as int),2) --> returns 0
Should return 2?
> Bug in N
nullif() as one column of
select statement and it ResultSetMetaData returns java.sql.Types.INTEGER.
Further Oracle works in same way.
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://nagoya.apache.org/jira/browse/DERBY-7
owing expressions?
nullif(1,2)
nullif(cast(null as int),2)
These expressions should return INTEGER and not CHAR!
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
> URL: http://nagoya.apache.org/jira/browse/DERBY-7
> Project: Derby
>
'INTEGER' and 'CHAR' are not supported.
i.e it works between type compatible expressions.
I will submit a patch soon.
Kindly verify and post any comments to this proposed solution.
> Bug in NULLIF Function
> --
>
> Key: DERBY-7
>
:
-
Key: DERBY-7
Summary: Bug in NULLIF Function
Type: Bug
Status: Unassigned
Priority: Minor
Project: Derby
Components:
SQL
Versions:
10.0.2.0
Assignee:
Reporter: Tulika Agrawal
Created: Mon, 27 Sep 2004 5:44 PM
Updated: Mon, 27
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I believe this is a known defect.. We will try to address this soon.
Satheesh
Christian d'Heureuse wrote:
| The NULLIF built-in function of Cloudscape 10.0.1.0 beta seems to accept
| only string values.
|
| Examples:
|
| values nullif('a','b');
| -->
The NULLIF built-in function of Cloudscape 10.0.1.0 beta seems to accept
only string values.
Examples:
values nullif('a','b');
--> OK
values nullif(1,2);
--> Error message: "ERROR 42X89: Types 'CHAR' and
'INTEGER' are not type compatible. (Neither type
is assignable to the other ty
53 matches
Mail list logo
