Teradata SQL VARCHAR et les espaces

Question

Je ne suis pas tout à fait quand je fais un plaine d'insertion de données numériques dans un champ varchar pourquoi est-il gauche pad avec 2 espaces. Est-ce que varchar n'est pas censé couper les espaces (trailing ok ... mais où est la règle que vous "frontpad" avec des espaces). Pourquoi pad puis avec 2 espaces principaux

INSERT INTO v VALUES (,1243444,3455435,8768810,'fdff',5,7,8,,) 

Ici (,1243444,3455435,8768810,'fdff',5,7,8,,) sont (someirrelvant_datatype,varchar(x),varchar(y),varchar(z),char(5),smallint,int,int,Timestamp)

donc des données se présente comme suit

SEL  CHAR2HEXINT (colA) ,colA FROM v 


313732353732 172572 /* this is some other pre-existing value*/ 
2020202033343535343335  3455435 /* this is value just inserted */ 

Donc, si vous voyez ci-dessus 20202020 Hex pour 2 spaces aka ' '

2ème question (pas continuation de la situation ci-dessus)
J'ai aussi données pour un varchar (50) col comme celui-ci

HMSA 
232434343 
HMSA 
4343434343 
434343434 

Ici, le HMSA a un espace de fin 2020 HEX mais d'autres valeurs n'ont pas trailing spaces. Pas sûr de ce qui se passe. Maintenant, voici varchar censé jeter tous les espaces de fuite? comment se fait-il que les données ont atterri avec HMSA<space> Pas sûr. Des idées ?

Ok permet donc de regarder quelques bizarreries venant de ceci:

insert ('yada ') into tb /* tb is volatile & SET.There are 4 spaces */ 
insert ('yada') into tb 

Query Failed. 2802: Duplicate row error in tb 

Bien voir ce que cela ressemble

7961646120202020 yada /*There are 4 spaces - 20 x 4 */ 

donc sur la 2ème insert il secouèrent la partie de comparaison de l'espace et fait un trim(oldvalue) vs trim (new value)

Answer 1

Q1: Lorsque vous exécutez un SELECT FORMAT(3455435), TYPE(3455435) vous obtenez -(10)9 0 Chaque type de données a toujours un format de style Cobol utilisé pour la conversion de et vers une chaîne. Dans votre cas, les types de données de la source et de la cible ne correspondaient pas et Teradata a fait un cast de type automatique. Le format d'un nombre entier comporte jusqu'à dix chiffres plus un signe principal aligend à droite.

La distribution de type Explixit à l'aide de la norme SQL CAST n'applique aucun format et donc aucun espace de début. Alors tout simplement faire CAST(3455435 AS VARCHAR(20) ou (TRIM (3455435) `à la place

Q2. A magasins VarChar exactement ce que vous insérez, c.-à-'1234 ' seront stockées, y compris deux espaces et sur la base des règles de comparaison standard SQL espaces de fin sont ignorés lorsque l'on compare les chaînes. , donc 'yada ' et 'yada' sont considérés comme égaux (vous avez probablement travaillé avec Oracle avant de ne pas suivre le standard SQL dans ce cas)