Anonymous

My feedback

  1. 348 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →

    Upvotes: 8

    <=-=Mar 5 2017 2:42PM=-=>

    Thanks for this idea. This is a valid requirement and I hope that it will get more votes. Currently we cannot confirm when it will be added, but it is in our backlog.

    <=-=May 22 2017 5:03AM=-=>

    would like it very much, particularly since you already have the CONCAT / GREATEST() a variable number of paramenters and does something with it…

    <=-=Jun 5 2017 12:31PM=-=>

    GREATEST / LEAST functions would be fantastic addition.

    <=-=Nov 14 2017 3:42PM=-=>

    The workarounds using CROSS APPLY or CASE expressions are difficult to manage and read. I’d love to see these implemented.

    Anonymous supported this idea  · 
  2. 93 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    7 comments  ·  SQL Server » Suggestions  ·  Flag idea as inappropriate…  ·  Admin →

    Upvotes: 289

    <=-=Aug 9 2007 9:12AM=-=>

    Benefits:
    Improved Readability, therefore Maintainablity, therefore reduced manpower $ and time expenditure.

    <=-=Aug 27 2007 6:13PM=-=>

    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

    <=-=Oct 17 2007 2:06PM=-=>

    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,…

    Anonymous supported this idea  · 
    Anonymous commented  · 

    I really think that ANSI be damned, the syntax IS [NOT] is much more readable than IS [NOT] DISTINCT FROM
    Definitely this should be implemented in T-SQL asap, it's already implemented in the query engine, there's just no easy way of writing it.

Feedback and Knowledge Base