Ola pessoal, bom dia, preciso de uma dica no postgres com relação a
uppercase e lowercase
Situação: select * from tabela where nome like '%stefan%';
Porem, se eu tiver cadastrado no banco Stefan ou STEFAN, o banco não
encontra pelo fato do casesensitive. Como posso flexibilizar isso para que o
2009/10/5 Stefan Horochovec stefan.horocho...@gmail.com
Ola pessoal, bom dia, preciso de uma dica no postgres com relação a
uppercase e lowercase
Situação: select * from tabela where nome like '%stefan%';
Porem, se eu tiver cadastrado no banco Stefan ou STEFAN, o banco não
encontra pelo
utiliza o ILIKE
Situação: select * from tabela where nome ilike '%stefan%';
Acho que isso já resolve seu problema!
2009/10/5 Stefan Horochovec stefan.horocho...@gmail.com
Ola pessoal, bom dia, preciso de uma dica no postgres com relação a
uppercase e lowercase
Situação: select * from tabela
Pessoal obrigado pelos retornos!!!
Bem, consegui importar para dento do PostgreSQL 8.4 e PostGIS 1.4 o meu antigo
banco de dados, creio que veio uma parte, mas o mais importante que eram as
tabelas foram restauradas pelo Pg-restore do Postgres, fiz várias tentativas e
instalei e re-instalei
Qual a melhor forma de mascarar um CPF, usando o POSTGRE?
Preciso de formatar o número 00123456789 em uma view, para retornar da
seguinte forma 001.234.567-89.
Att,
RAUL MAIA DA SILVA
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
2009/10/5 Raul Maia da Silva raul.m...@gmail.com
Qual a melhor forma de mascarar um CPF, usando o POSTGRE?
Preciso de formatar o número 00123456789 em uma view, para retornar da
seguinte forma 001.234.567-89.
Att,
RAUL MAIA DA SILVA
Eu fiz assim:
postg...@bdteste=# select
Raul Maia da Silva escreveu:
Preciso de formatar o número 00123456789 em uma view, para retornar da
seguinte forma 001.234.567-89.
Existem várias formas de se fazer isso mas uma delas está em [1] (formatcpf).
[1]
2009/10/5 Fabrízio de Royes Mello fabriziome...@gmail.com
Eu fiz assim:
postg...@bdteste=# select replace(to_char(00123456789, '000:000:000-00'),
':', '.');
replace
-
001.234.567-89
(1 row)
Complementando... como você não especificou o tipo de dado do valor do
Olá a todos,
esta é a minha primeira mensagem na lista :)
bom, tenho a seguinte situação: alterei um campo, que é chave
primária, e quero alterar o conteúdo deste campo em todos os registros
(acrescentar um zero à esquerda de um campo VARCHAR).
já imaginam o problema né? os dependentes não
Marinho Brandao escreveu:
bom, tenho a seguinte situação: alterei um campo, que é chave
primária, e quero alterar o conteúdo deste campo em todos os registros
(acrescentar um zero à esquerda de um campo VARCHAR).
já imaginam o problema né? os dependentes não permitem isso.
pois é, a forma
Bom Dia Amigos,
Aproveitando a discussão... Em sistemas robustos (grande número de dados)
costumo utilizar o campo CPF como BIGINT.
Assim se tem uma economia de espaço já que se gasta menos bytes com BIGINT
do que com tipos CHAR em geral.
Pois se for usar tipos CHAR em geral para armazenar CPF,
Fernando, apenas para não existir erros de interpretação, pois relendo agora
a frase eu mesmo demorei a compreender o que escrevi. Faltou pontuação na
mesma... rss
Com a pontuação adequada ficaria:
Concordo com o que o Euler colocou sobre a quantidade excessiva de índices.
Uma vez que o SGBD não
OLá Charly,
Me corrija se estiver errado, de acordo com o que você escreveu não importa
se eu tenho 1 ou 50 indices em uma tabela, pois quando faço uma consulta ao
banco o SGBD utiliza muito poucos indices para realiza-la.
certo?
abraços, obrigado pela ajuda.
2009/10/5 Charly Frankl
Opa,
O PostgreSQL permite que você faça isso tudo dentro de um bloco de transação.
é o que eu estou evitando :P
- alterar a constraint para ativar o ON UPDATE CASCADE
Sim.
sabe a URL que explique ou pode me explicar como se faz?
obrigado! :)
--
Marinho Brandão (José Mário)
Muito bom Osvaldo !!! Simples e objetivo !!!
Sempre acreditei que teria uma maneira mais simples...
Na próxima vez usarei essa maneira by Osvaldo ! rsss...
Abraços !
-Mensagem original-
De: pgbr-geral-boun...@listas.postgresql.org.br
[mailto:pgbr-geral-boun...@listas.postgresql.org.br]
2009/10/5 Osvaldo Kussama osvaldo.kuss...@gmail.com
Mas não precisa usar a função replace:
bdteste=# SELECT to_char(01234567890,'000.000.000-00') AS cpf;
cpf
-
012.345.678-90
(1 registro)
bdteste=# SELECT to_char(12345678000199,'00.000.000/-00') AS
cnpj;
Charly Frankl escreveu:
Resumindo, a cada consulta o SGBD elege APENAS UM índice da entidade
para ser utilizado na consulta.
É claro que não. O SGBD pode escolher quantos índices quiser; isso vai
depender da consulta que você está executando.
--
Euler Taveira de Oliveira
2009/10/5 Euler Taveira de Oliveira eu...@timbira.com
É claro que não. O SGBD pode escolher quantos índices quiser; isso vai
depender da consulta que você está executando.
Mas isso é válido se o enable_bitmapscan estiver habilitado, porque se
estiver desligado o planejador vai usar (ou não)
Olá Fabrizio,
Veja:
http://www.postgresql.org/docs/8.4/interactive/sql-createtable.html
hummm... nessa página eu só encontrei sobre *criar* campos com
constraints... eu estou procurando saber como se *altera* uma
constraint já existente (sem ter de excluí-la e criar novamente). Isso
é
Fabrízio de Royes Mello escreveu:
2009/10/5 Euler Taveira de Oliveira eu...@timbira.com
mailto:eu...@timbira.com
É claro que não. O SGBD pode escolher quantos índices quiser; isso vai
depender da consulta que você está executando.
Mas isso é válido se o enable_bitmapscan estiver
2009/10/5 Marinho Brandao mari...@gmail.com
hummm... nessa página eu só encontrei sobre *criar* campos com
constraints... eu estou procurando saber como se *altera* uma
constraint já existente (sem ter de excluí-la e criar novamente). Isso
é possível?
Como o Euler já comentou não existe
Marinho Brandao escreveu:
hummm... nessa página eu só encontrei sobre *criar* campos com
constraints... eu estou procurando saber como se *altera* uma
constraint já existente (sem ter de excluí-la e criar novamente). Isso
é possível?
Não existe ALTER CONSTRAINT. Como eu disse anteriormente
2009/10/5 Euler Taveira de Oliveira eu...@timbira.com
Como eu disse anteriormente, o planejador pode produzir um plano que
utiliza
mais do que um índice por tabela. Por exemplo, em junções com a mesma
tabela e
quando a tabela aparece em mais de um nó no plano de execução.
Tranquilo...
Olá Euler,
Não existe ALTER CONSTRAINT. Como eu disse anteriormente você terá que
utilizar um bloco de transação contendo ALTER TABLE foo DROP CONSTRAINT e
ALTER TABLE foo ADD FOREIGN KEY.
veja o que você disse:
- dar um UPDATE ... SET ... CASCADE (ou algo semelhante) para
atualizar os
Charly,
É por ai mesmo. Na verdade, você pode ter os 50 índices na tua tabela,
mas
quando for consultá-la o SGBD vai eleger UM índice a ser utilizado para a
consulta. Logo, ter 50 índices não é garantia de melhoria na performance
da
pesquisa, mas alguns índices bem planejados vão com certeza
Olá,
não entendi direito sua dúvida mas as geometrias ficam armazenadas em
formato binário mesmo. Para converte-las para texto, só usando st_astext e
afins.
Ou seja, armazenar em formato binário é o comportamento esperado.
[]'s
Luigi Castro Cardeles
2009/10/5 Nelson Marisco
De fato, nas versões apartir da 8.2 (se nao me engano) o postgresql consegue
simular um indice bitmap em memória, mas como disposto também em [1]:
A condição pode ser dividida em n utilizações separadas de um índice sobre
uma condição where. Depois é verificado o operador. Depois de os resultados
Fabrízio de Royes Mello escreveu:
Tranquilo... isso eu sabia... mas no mesmo nó somente com o bitmapscan
para utilizar mais de um índice né?
Não, com os algoritmos de junção podemos ter buscas em vários índices
simultaneamente também.
--
Euler Taveira de Oliveira
http://www.timbira.com/
Mozart, boa tarde... Acho que não entendeu bem quando eu usei o termo
apenas um índice por tabela.
Como pode ver, o otimizador notou, pela distribuição dos dados, que
compensa
usar um índice diferente para cada citação da tabela dentro da mesma
consulta (i1tbcidade e a1tbcidade).
Como você
Marinho,
Se entendi o teu problema, você quer um UPDATE CASCADE, certo?
Logo, como não tem definido alter constraint, basta remover a antiga e criar
uma nova com a sitaxe definida em [1]:
ALTER TABLE tbl1 ADD CONSTRAINT fk_tbl1_tbl2 FOREIGN KEY (coluna1)
REFERENCES tbl2 ( coluna1 ) ON DELETE
Olá Charly,
sim, é isso que eu sempre fiz, mas como vi que o DROP COLUMN tinha o
CASCADE, imaginei que talvez tivesse o equivalente para o ALTER ou
UPDATE ou quem sabe um ALTER CONSTRAINT.
por isso perguntei na lista :)
mas já está esclarecido, vou continuar fazendo da forma que eu sempre
fiz
31 matches
Mail list logo
