Obrigado Dickson, muito útil
Vai dar jeito...
Abraço
Em 04-06-2012 17:34, Dickson S. Guedes escreveu:
Em 4 de junho de 2012 06:42, Pedro Costapedrocostaa...@sapo.pt escreveu:
Olá pessoal,
Eu tenho um servidor ubuntu com uma base em postgres.
Pretendia importar um ficheiro .csv e
Então pessoal.
A ideia é ter um usuário desenvolvimento para todas as bases que tem nesse
servidor..Só uma observação.Todas as tabelas estão no schema public e nao
tem como migrar por causa das aplicações que são antigas.Da forma que eu
fiz nao estar funcionando o usuário estar tendo permissao de
2012/6/6 Emerson Martins emersonmarti...@gmail.com:
Todas as tabelas estão no schema public e nao
tem como migrar por causa das aplicações que são antigas.
Nem usando o caminho de busca dos esquemas?
___
pgbr-geral mailing list
Acredito que não..Se eu nao me engano foram desenvolvidos em Django.A
intenção desse usuário era somente as consultas mesmo..Pois por questão de
segurança quero eximir as demais permissões..
Emerson Martins
DBA Jr
Em 6 de junho de 2012 10:01, Guimarães Faria Corcete DUTRA, Leandro
2012/6/6 Emerson Martins emersonmarti...@gmail.com:
Acredito que não..Se eu nao me engano foram desenvolvidos em Django.
O caminho de busca de esquemas nada tem a ver com o aplicativo, é
configurável na base. Te permite tirar os objetos do esquema público
mas mantê‐los visíveis por aplicações
Entendi Dutra..Obrigado pelos esclarecimentos.Se tiver algum link que me
mostre a indicação na prática eu agradeço.
Emerson Martins
DBA Jr
Em 6 de junho de 2012 10:26, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
2012/6/6 Emerson Martins emersonmarti...@gmail.com:
Olá,
Como o nosso mestre Dutra comentou, depende muitos dos requisitos. Um banco
único é mais simples de manipular os dados e também de realizar o
gerenciamento, como backup e outras atividades.
Só tome cuidado para um cliente não ter acesso aos dados de outros clientes.
Com relação a Data
Eu resolvo isso de uma maneira simples: coloco uma coluna usuário em
todas as tabelas que requerem este controle via log. Esta coluna equivale
ao último usuário que mexeu na tabela, e deve sempre ser atualizada junto
com qualquer outra coluna que seja modificada por algum usuário. Assim o
trigger
*PostgreSQL em Florianópolis vem aí!*De *16 a 31 de Julho*, a
*Dextra*oferecerá treinamento PostgreSQL em Florianópolis com os
cursos:
- PostgreSQL Essencial - 24h
- PostgreSQL Linguagem Procedural - 16h
- PostgreSQL Administração do Banco de Dados - 24h
- PostgreSQL Performance
Pessoal, rodamos PostgreSQL 8.4.8 em cima de um Slackware, Kernel 2.6.38.
Não temos problemas de performance nem nada, e estive lendo sobre o
parâmetro bgwriter_delay cujo valor padrão é 200ms, será que se eu
abaixasse esse valor para digamos 50ms seria algo saudável? É mais uma
curiosidade e uma
Em 06-06-2012 15:02, Vinicius Santos escreveu:
Pessoal, rodamos PostgreSQL 8.4.8 em cima de um Slackware, Kernel 2.6.38.
Não temos problemas de performance nem nada, e estive lendo sobre o
parâmetro bgwriter_delay cujo valor padrão é 200ms, será que se eu
abaixasse esse valor para digamos
On 05-06-2012 15:21, Emerson Martins wrote:
Olá pessoal segue como eu fiz...
CREATE ROLE desenvolvimento ENCRYPTED PASSWORD 'pass';
ALTER Role desenvolvimento NOSUPERUSER;
ALTER ROLE desenvolvimento LOGIN;
ALTER ROLE desenvolvimento SET search_path='public';
REVOKE ALL ON SCHEMA public
Olá amigos.. gostaria de saber se alguém já passou pela experiência de
migrar um banco versão 7.4 para 9..
Quais foram as principais dificuldades? Tem alguma recomendação ou dica
importante? Utilizou pg_dump/pg_restore ou pg_upgrade?
Obrigado,
Renato
Olá amigos.. gostaria de saber se alguém já passou pela experiência de
migrar um banco versão 7.4 para 9..
Eu.
Quais foram as principais dificuldades? Tem alguma recomendação ou dica
Basicamente, casts implícitos, coisas que a especificação SQL não aceita
e o PostgreSQL implementou depois
14 matches
Mail list logo
