O problema é se você usa
char ou varchar2 semântica de comparação em suas consultas. Se você tiver um literal de string codificado ou um char(10) variável, o Oracle usa o char semântica de comparação que deve ignorar o espaço em branco à direita. Se você tiver um varchar2(10) variável, o Oracle usa a variável varchar2 semântica de comparação que inclui o espaço em branco à direita. Desta forma select aa
into v_temp
from abc
where aa in (v_aa);
retornará uma linha se
v_aa é definido como um char(10) (ou se for substituído por uma string literal), mas não se for definido como um varchar(10) . Esta é uma das (muitas) razões pelas quais a maioria das pessoas evita
char tipos de dados inteiramente. Pessoalmente, não me importo com o ocasional char para dados de largura realmente fixa (ou seja, char(1) para sinalizadores e char(2) para códigos de estado) mesmo que não haja nenhum benefício em usar char sobre varchar2 nesses cenários. Para qualquer coisa que não seja de largura fixa, no entanto, usando um char não faz sentido. Você está apenas forçando o Oracle a consumir mais espaço do que o necessário e criando mais trabalho para você mesmo lidando com dois conjuntos de semântica de comparação de strings (entre outros problemas). 
