Normalmente quem manipula constantemente com muitos arquivos, principalmente importa\u00e7\u00e3o e exporta\u00e7\u00e3o sempre se depara com arquivos sem layout definido, formata\u00e7\u00f5es incorretas, enfim, diversos problemas que dificultam o trabalho de manipula\u00e7\u00e3o do arquivo.<\/p>\n\n\n\n

Na minha situa\u00e7\u00e3o, sempre recebo planilhas com informa\u00e7\u00f5es de clientes e, nestas planilhas sempre tenho o CPF do cliente. Para quem trabalha bastante com as ferramentas de c\u00e1lculo dispon\u00edveis no mercado sabe que, normalmente quando o CPF possui zeros a esquerda, estes s\u00e3o ‘eliminados’ pela ferramenta e, quando importamos isto para nosso banco de dados a informa\u00e7\u00e3o vai incorreta.<\/p>\n\n\n\n

Montar um script padr\u00e3o ou desenvolver um sistema para importa\u00e7\u00e3o destes arquivos \u00e9 o ideal, mas isto quando trabalhamos com um layout definido.Outra sa\u00edda seria abrir a planilha e definir o tamanho do campo, mas ai perderia a gra\u00e7a fazer isto, pois, n\u00e3o ter\u00edamos este post (:d). Deixando o contexto de lado, vamos a situa\u00e7\u00e3o na pr\u00e1tica.<\/p>\n\n\n\n

Minha importa\u00e7\u00e3o de clientes \u00e9 feita para a tabela pessoa, que possui a seguinte estrutura:<\/p>\n\n\n\n

 CREATE TABLE public.pessoa (  \n  id_pessoa       integer NOT NULL,  \n  nome         varchar(100),  \n  cpf      varchar(30) NOT NULL,  \n  dtm_cadastro     timestamp WITHOUT TIME ZONE NOT NULL DEFAULT now(),  \n  id_usuario_cadastro  bigint NOT NULL,  \n  dtm_alteracao     timestamp WITHOUT TIME ZONE DEFAULT now(),  \n  id_usuario_alteracao bigint,  \n  \/* Keys *\/  \n  CONSTRAINT pessoa_pkey  \n   PRIMARY KEY (id_pessoa)  \n ) WITH (  \n   OIDS = FALSE  \n  );  \n<\/code><\/pre>\n\n\n\n
Nesta tabela possuo o seguinte registro:<\/p>\n\n\n\n
 Select id_pessoa,nome,cpf From pessoa;  \n 1     Papo Sql     123456789  \n<\/code><\/pre>\n\n\n\n
Como podemos ver o CPF existente em minha tabela esta incorreto, pois, possui apenas nove n\u00fameros. Sabendo que o CPF possui 11 n\u00fameros usamos ent\u00e3o a fun\u00e7\u00e3o lpad para completar com zeros \u00e0 esquerda.<\/p>\n\n\n\n
<\/a>
A fun\u00e7\u00e3o possui a seguinte estrutura de sintaxe:<\/p>\n\n\n\n
lpad<\/code>(<\/span>string<\/tt> <\/span>text<\/tt>, <\/span>length<\/tt> <\/span>int<\/tt>[<\/span>, fill<\/tt> text<\/tt><\/span>])<\/span><\/p>\n\n\n\n
Primeira posi\u00e7\u00e3o (string text), deve ser inserido o campo qual pretende-se completar com a sequencia de caracteres.<\/p>\n\n\n\n
Segunda posi\u00e7\u00e3o (length int), deve ser informado o tamanho a ser retornando pela fun\u00e7\u00e3o.<\/p>\n\n\n\n
Terceira posi\u00e7\u00e3o (fill text), deve ser informado o valor que ser\u00e1 inserido\/repetido \u00e0 esquerda do campo.<\/p>\n\n\n\n
Em nosso exemplo ent\u00e3o teremos:<\/p>\n\n\n\n
 Select id_pessoa,nome,lpad(cpf,11,'0') From pessoa;  \n 1     Papo Sql     00123456789  \n<\/code><\/pre>\n\n\n\n
Pronto, campo completado, mas n\u00e3o resolvido o problema, pois, temos apenas um select, a informa\u00e7\u00e3o na tabela ainda est\u00e1 incorreta, para corrigir isto realizamos a atualiza\u00e7\u00e3o do valor:<\/p>\n\n\n\n
 update pessoa  \n set cpf = lpad(cpf,11,'0')  \n where id_pessoa = 1;  \n<\/code><\/pre>\n\n\n\n
Um ponto a se ressaltar \u00e9, o retorno da fun\u00e7\u00e3o sempre ser\u00e1 texto, caso o campo a ser atualizado seja um inteiro, dever\u00e1 haver um convers\u00e3o de dados.<\/p>\n\n\n\n
Voltando ao in\u00edcio do post, mencionei a importa\u00e7\u00e3o e exporta\u00e7\u00e3o, ent\u00e3o pontuando brevemente sobre a exporta\u00e7\u00e3o, podemos usar este mesmo contexto, agora exportando os dados do cliente.<\/p>\n\n\n\n
Digamos que agora na exporta\u00e7\u00e3o eu tenha um layout predefinido para seguir e, nele o meu campo CPF tem tamanho 14, devido ao layout prever pessoas f\u00edsicas e jur\u00eddicas, ent\u00e3o eu fa\u00e7o:<\/p>\n\n\n\n
 Select id_pessoa,nome,lpad(cpf,14,' ') From pessoa;  \n 1     Papo Sql    '   00123456789'  \n<\/code><\/pre>\n\n\n\n
Veja que neste caso eu preenchi com espa\u00e7os, pois, nosso cliente \u00e9 uma pessoa f\u00edsica, n\u00e3o jur\u00eddica.<\/p>\n\n\n\n
Como podemos ver, a fun\u00e7\u00e3o lpad pode ser utilizada de diversas formas, o que vai variar somente \u00e9 o contexto. Aqui discutimos sua usabilidade no PostgreSQL, mas ela tamb\u00e9m \u00e9 nativa no MySQL e  Oracle.<\/p>\n\n\n\n
Agora, caso precise fazer tudo que fizemos adicionando valores a direta, inverta o l<\/b>pad para r<\/b>dad, fun\u00e7\u00e3o que possui a mesma estrutura de sintaxe do lpad.<\/p>\n\n\n\n
Grande abra\u00e7o e at\u00e9 a pr\u00f3xima.<\/p>\n\n\n\n
Material de refer\u00eancia:
http:\/\/www.postgresql.org\/docs\/8.2\/static\/functions-string.html<\/a>
http:\/\/ricardospinoza.wordpress.com\/2010\/08\/13\/preencher-zeros-a-esquerda-com-funcao-oracle\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Normalmente quem manipula constantemente com muitos arquivos, principalmente importa\u00e7\u00e3o e exporta\u00e7\u00e3o sempre se depara com arquivos sem layout definido, formata\u00e7\u00f5es incorretas, enfim, diversos problemas que dificultam o trabalho de manipula\u00e7\u00e3o do arquivo. Na minha situa\u00e7\u00e3o, sempre recebo planilhas com informa\u00e7\u00f5es de clientes e, nestas planilhas sempre tenho o CPF do cliente. Para quem trabalha bastante … Ler mais<\/a><\/p>\n","protected":false},"author":1,"featured_media":793,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[31],"tags":[],"class_list":["post-471","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-postgresql"],"yoast_head":"\n