Em Qua 23 Jan 2008 14:46, Euler Taveira de Oliveira escreveu: > Marlon David de Souza wrote: > > > Segue abaixo um FAQ que eu escrevi com o objetivo de ajudar a quem usa o > > Firebird e quer usar também o PostgreSQL. > > Caso achem interessante, alguém poderia colocar no portal do > > postgresql.org.br. > > > Seria apropriado mas com algumas correções... > > > -------------------------------------------------------------------------------- > > > > P: Tem como desativar Triggers e Índices? > > > > R: Diferente do Firebird, no Postgres não é possivel desativar uma Trigger > > ou > > um Índice. O que pode ser feito é excluí-los e posteriormente > > reinclui-los > > quando necessário. > > > Tem sim. A partir da 8.1 os gatilhos podem ser desabilitados [1]. > Eu montei essa documentação quando o PGS estava na versão 8.0. Vou corrigir. > > > -------------------------------------------------------------------------------- > > > > P: Que utilitários estão disponíveis? > > > > R: Segue abaixo a lista de alguns utilitários e seu similar em Firebird. > > > > PSql: Similar ao ISql > > pgAdmin3: Similar ao IBConsole > > EMS SQL Manager: Similar ao IBExpert > Eu *não* aconselho favorecer somente um produto pois nesta categoria tem > vários outros produtos. > Por isso eu coloquei a frase "alguns utilitários".
> > > -------------------------------------------------------------------------------- > > > > P: Onde ficam armazenadas as mensagens geradas pelo Postgres? > > > > R: As mensagens de inicialização ficam no arquivo "pgstartup.log". Já as > > mensa- > > gens de operações realizadas pelo banco ficam em arquivos armazenados no > > diretório "pg_log". > > > pgstartup.log ? Isso não é padrão. Nem mesmo o pg_log está habilitado > por padrão. > Vou colocar que é possivel personalizar o log atravez de configuração. Quanto ao "pgstartup.log" não me lembro da onde eu tirei isso. Agora é "serverlog", certo? > > -------------------------------------------------------------------------------- > > > > P: Existem instaladores dos binários para Linux? > > > > R: Oficialmente existem instaladores somente para RedHat/AS, RedHat/ES e > > Fedora. > > Nas demais distribuições é necessário baixar os fontes e compilar. No > > entanto, > > independente da distribuição, o ideal é compilar, pois isso deixa o > > Postgres > > otimizado para o hardware usado. > > > Seria interessante não restringir. Coloque que existem binários para > Windows também. Eu trocaria a segunda frase dizendo que a maioria das > distribuições Linux distribuem o PostgreSQL. > Ok. > > > -------------------------------------------------------------------------------- > > > > P: Se alguém fizer uma cópia da base de dados e levá-la para outra máquina, > > ele poderá acessar os dados, assim como acontece com o FireBird? > > > > R: Sim. Mas o mesmo acontece com outros bancos como o Oracle, DB2, etc. > > > Tome muito cuidado com esta resposta. Se o hardware for diferente pode > ser que não funcione. Até mesmo o jeito de compilar o PostgreSQL pode > fazer diferença mesmo que o hardware seja idêntico. > O que você quis dizer com cópia da base de dados? Utilizando pg_dump? > Caso o servidor PostgreSQL não esteja parado, uma cópia "quente" dos > dados pode não funcionar também. > Esqueci de colocar que é uma cópia via pg_dump. > > > -------------------------------------------------------------------------------- > > > > P: Como saber se uma base está corrompida? > > > > R: vacuumdb -U sysdba -d <nome da base> -v > > > De onde você tirou isso?? O PostgreSQL *não* corrompe base! E, mesmo se > corrompesse, o vacuumdb *não* serve para isso. Sugiro retirar esta pergunta. > Esqueci de colocar os motivos (hardware, S.O, energia, etc) > > > -------------------------------------------------------------------------------- > > > > P: Exite alguma ferramenta para reparar bases corrompidas? > > > > R: Algumas podem ser encontradas nos seguintes sites: > > - http://svana.org/kleptog/pgsql/pgfsck.html > > - http://www.hjackson.org/blog/archives/2004/12/postgresql_data.html > > > Sugiro retirar isso também. Os erros que corrompem a base de dados > geralmente são na sua grande maioria ou por conta do kernel ou por > problemas de hardware (memória, disco). > idem. > > -------------------------------------------------------------------------------- > > > > P: Em acesso local, é mais rápido usar "localhost" em vez do IP? > > > > R: Sim, pois com "localhost" os pacotes não passam pela placa de rede. > > > Ugh? Muito confusa a pergunta e a resposta também. Sugiro retirar. É > meio óbvio isso. > ok. > > > -------------------------------------------------------------------------------- > > > > P: Existem Store-Procedures no Postgres? > > > > R: Não. Mas as funções podem desempenhar o mesmo papel. > > > Retire o "podem". Elas desempenham. > ok. > > > -------------------------------------------------------------------------------- > > > > P: O processo do "Vacuum" irá travar a base? > > > > R: Sim, se for usada a opção "-f". > > > O vacuum [2] *não* trava a base. Ela trava os objetos da base se for > utilizado com a opção --full. > Tanto faz usar "-f" ou "--full" > > > -------------------------------------------------------------------------------- > > > > P: Qualquer erro dento de uma transação irá aborta-lá? > > > > S: Sim. Será efetuado um "rollback". > > > Tome cuidado aqui. Se estiver utilizando pontos de salvamento (aka > savepoints) a história muda um pouco. > ok. > > > -------------------------------------------------------------------------------- > > > > P: Quais são os formatos de data e hora que podem ser usados? > > > > R: "dd/mm/aaaa", "dd.mm.aaaa", "aaaa-mm-dd" e "dd-mm-aaaa" para datas e > > "hh:mm:ss" para horas. > > > Pergunta cuja resposta é meio óbvia. Sugiro retirar. > Essa foi uma dúvida que eu tive ao portar um sistema que usava Firebird para usar tambem o Post. > > > -------------------------------------------------------------------------------- > > > > P: Que tipo de campo deve ser usado para armazenar dados binários? > > > > R: Use o tipo "bytea". > > > Eu acrescentaria objetos grande (aka large objects) aqui também. > O tipo "bytea" é o que mais se assemelha ao que existe no Firebird. Quem portar do FB, provavelmente irá usá-lo. Vou colocar como observação que existe o "large objects". > > > -------------------------------------------------------------------------------- > > > > P: Para que serve o OID? É necessário usá-lo. > > > > R: É um identificador único para cada registro. Pode ser usado para fazer > > rela- > > cionamento de registro entre tabelas. Se ele for usado para isso, no > > proces- > > so de backup deve ser especificado para que esta informação seja gerada > > junto > > com os dados. > > > Leia [3]. Eu não aconselharia o uso do tipo OID em tabelas. Por padrão, > as tabelas não são criadas com OIDs desde a versão 8.1. > ok. > > > -------------------------------------------------------------------------------- > > > > P: Quanto tempo leva para respoder quando é gerado um "deadlock"? Na hora ou > > somente quando é encerrada (commit) a transação que está bloqueando o > > regis- > > tro? > > > > R: Somente quando é encerrada. Mas, ao contrário do Firebird, não gera > > "DeadLock". Passa a valer a alteração feita pela última transação > > efetuada. > > > Ugh? Sugiro ler [4] e reformular a pergunta e resposta. > Ok, vou tentar ser mais claro. > > > -------------------------------------------------------------------------------- > > > > P: Como são classificados os campos com conteúdo NULO? > > > > R: É igual ao do Firebird, ou seja, o valor nulo classifica-se mais alto do > > que > > outro valor. > > > A partir da versão 8.3 [5] isso mudou. Veja ORDER BY foo NULLS {FIRST|LAST}. > ok, vou citar isso. > > -------------------------------------------------------------------------------- > > > > P: Como comportam-se funções de agregação (SUM, etc) quando existe nulos? > > > > R: Os valores nulos não são considerados. > > > Isso é do padrão SQL, não? Eu não incluiria esta pergunta. > Ok. > > > -------------------------------------------------------------------------------- > > > > P: Como comportam-se cálculos contendo campos nulos (Ex: 1 + null)? > > > > R: Qualquer operação em que um dos valores seja "null" o resultado será > > sempre > > "null". Para evitar isso, pode ser utilizada a função "coalesce". > > > Novamente o padrão SQL cobre isso. Eu não incluiria. > Ok. > > > -------------------------------------------------------------------------------- > > > > P: Quando é feita uma consulta envolvendo agrupamento (group by), no > > Firebird a > > lista retorna ordenada conforme os campos do agrupamento. Como isso > > funciona > > no Postgres? > > > > R: Já no PGS isso não ocorre. Portanto, quando for utilizar uma consulta com > > agrupamento e deseja que os dados retornem ordenados, é necessário usar a > > clausula "order by". > > > Esta resposta é meio óbvia, não? Quem estudou teoria de banco de dados > sabe que relações (aka conjuntos) não garantem a ordem de retorno dos dados. > Fiz um pequeno teste e ambos retornaram os dados ordenados. -- ---------------------------------- Sem mais, Marlon David de Souza Desenvolvimento Sysmo Informática Ltda _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
