sql >> Database >  >> RDS >> Sqlserver

SQL Server:+(unaire) operator op niet-numerieke strings

Hier is mijn eigen antwoord op deze vraag (zie ook de update aan het einde):

Nee, er is niet zo'n unaire operator gedefinieerd voor de String-expressies. Het is mogelijk dat dit een bug is.

Uitleg:

De gegeven verklaring is geldig en genereert het onderstaande resultaat:

(No column name) 
----------------
ABCDEF
(1 row(s) affected)

wat gelijk staat aan het doen van de SELECT statement zonder de + teken:

SELECT  'ABCDEF'

Gecompileerd worden zonder fouten te geven, in feite succesvol worden uitgevoerd, wekt de indruk dat + werkt als een Unary bewerking op de gegeven string. In de officiële T-SQL documentatie, is er geen sprake van een dergelijke operator. In de sectie getiteld "String Operators ", + verschijnt in twee tekenreeksbewerkingen, namelijk + (String Concatenation) en += (String Concatenation); maar geen van beide is een Unary operatie. Ook in de sectie getiteld "Unary Operators ", zijn er drie operators geïntroduceerd, waarvan er slechts één de + (Positive) . is exploitant. Echter, voor deze enige die relevant lijkt, wordt al snel duidelijk dat ook deze operator niets te maken heeft met niet-numerieke stringwaarden als verklaring voor + (Positive) operator geeft expliciet aan dat deze operator alleen van toepassing is op numerieke waarden:"Retourneert de waarde van een numerieke uitdrukking (een unaire operator) ".

Misschien is deze operator er om met succes die tekenreekswaarden te accepteren die met succes als getallen zijn geëvalueerd, zoals degene die hier is gebruikt:

SELECT  +'12345'+1

Wanneer de bovenstaande instructie wordt uitgevoerd, genereert het een getal in de uitvoer dat de som is van zowel de gegeven string die wordt geëvalueerd als een getal en de numerieke waarde die eraan wordt toegevoegd, namelijk 1 hier, maar het kan natuurlijk elk ander bedrag zijn:

(No column name) 
----------------
12346
(1 row(s) affected)

Ik betwijfel echter of deze uitleg de juiste is, aangezien het de onderstaande vragen oproept:

Ten eerste, als we accepteren dat deze verklaring waar is, dan kunnen we concluderen dat uitdrukkingen zoals +'12345' worden tot cijfers beoordeeld. Als dat zo is, waarom kunnen deze getallen dan voorkomen in de tekenreeksgerelateerde functies zoals DATALENGTH , LEN , enz. Je zou een verklaring als deze kunnen zien:

  SELECT  DATALENGTH(+'12345')

is redelijk geldig en resulteert in het onderstaande:

 (No column name) 
----------------
5
(1 row(s) affected)

wat betekent +'12345' wordt geëvalueerd als een tekenreeks, niet als een getal. Hoe kan dit worden verklaard?

Ten tweede, terwijl soortgelijke uitspraken met - operator, zoals deze:

 `SELECT  -'ABCDE'` 

of zelfs dit:

`SELECT  -'12345'` 

genereer de onderstaande fout:

Invalid operator for data type. Operator equals minus, type equals varchar.

Waarom, zou het geen fout moeten genereren voor soortgelijke gevallen wanneer + operator is ten onrechte gebruikt met een niet-numerieke tekenreekswaarde?

Deze twee vragen weerhouden me er dus van om de uitleg te accepteren dat dit hetzelfde is + (unary) operator die is geïntroduceerd in de documentatie voor numerieke waarden. Omdat het nergens anders wordt genoemd, kan het zijn dat het opzettelijk aan de taal is toegevoegd. Kan een bug zijn.

Het probleem lijkt ernstiger te zijn als we zien dat er ook geen fout wordt gegenereerd voor uitspraken als deze:

SELECT ++++++++'ABCDE'

Ik weet niet of er andere programmeertalen zijn die dit soort uitspraken accepteren. Maar als die er zijn, zou het leuk zijn om te weten voor welk(e) doel(en) ze een + (unary) gebruiken operator toegepast op een string. Ik kan me geen gebruik voorstellen!

UPDATE

Hier staat dat dit een bug was in eerdere versies, maar het zal niet worden opgelost vanwege achterwaartse compatibiliteit:

Na enig onderzoek is dit gedrag inherent aan het ontwerp aangezien + een unaire operator is. Dus de parser accepteert "+ , en de '+' wordt in dit geval gewoon genegeerd. Het wijzigen van dit gedrag heeft veel implicaties voor achterwaartse compatibiliteit, dus we zijn niet van plan het te veranderen en de correctie zal onnodige wijzigingen in de applicatiecode introduceren.




  1. Gebruikerswaarschuwingen beheren

  2. Mysql-query met telling Resource-id #11

  3. pass object van Java naar Oracle procedure

  4. Hoe SQL Server-database migreren naar MySQL?