Search
Active

102
Sign in to vote
0
Sign in to vote
Sign in
to vote
Type: Suggestion
ID: 286422
Opened: 7/7/2007 12:30:11 PM
Access Restriction: Public
Duplicates: 307476
0
Workaround(s)
SQL 1999 and later include the <distinct predicate> IS [NOT] DISTINCT FROM.

The definition of distinct is (quoting from the 2003 standard) "informally, not equal, not both null." This is consistent with where SQL Server (following the standard) already uses the keyword DISTINCT. Adding <distinct predicate> to T-SQL would simplify coding of joins, in particular, and as of 2008, MERGE statements in a variety of typical scenarios.

Example:

SELECT T1.this, T2.that
FROM T1 JOIN T2
ON T1.entry IS NOT DISTINCT FROM T2.entry

Currently, this must be written as

SELECT T1.this, T2.that
FROM T1 JOIN T2
ON (
T1.entry = T2.entry
OR
(T1.entry IS NULL AND T2.entry IS NULL)
)

This is a common requirement, but coding this for many columns is both tedious and error-prone (especially because of AND/OR precedence issues). Changing the setting of ANSI_NULLS is not a solution, because it does not affect column-to-column comparisons, only column to variable comparisons. Setting ANSI_NULLS to off is also non-standard and not granular enough to apply to specific comparisons in a single query.
Details (expand)
Product Language
English

Category

SQL Engine
Proposed Solution
Add support for the ISO standard <distinct predicate> to T-SQL. Over time, add optimization support for the typical uses of this predicate.
Reference: ISO/IEC 9075-2:2003 (E) section 8.14
Benefits
Faster Development
Improved Reliability
Improved Performance
Other (please provides details below)
Other Benefits
Further compliance with ISO SQL standards
File Attachments
0 attachments
Sign in to post a comment.
Posted by SAinCA on 8/9/2007 at 9:12 AM
Benefits:
Improved Readability, therefore Maintainablity, therefore reduced manpower $ and time expenditure.
Posted by Microsoft on 8/27/2007 at 6:13 PM
I definitely see the value of this. Thanks for proposing it. We'll try to squeeze it in to SQL Server 2008 but things are really tight in terms of room for changes like this. It has to compete with many other things, including a bunch that have a larger impact on query performance, or that don't have an easy workaround. This issue has a workaround, though it is not pretty and programmability would be enhanced a lot with the proposed enhancement. I'll see what I can do.

Best regards,
Eric
Posted by Microsoft on 10/17/2007 at 2:06 PM
Things do not look good for this enhancement for Katmai. It probably will not make it into the release. We'll make a final assessment in a couple of weeks. Before we can consider this, we have to finish other commitments.