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]. > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > 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). > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > P: Existem Store-Procedures no Postgres? > > R: Não. Mas as funções podem desempenhar o mesmo papel. > Retire o "podem". Elas desempenham. > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > 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}. > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > 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. > -------------------------------------------------------------------------------- > > 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. [1] http://www.postgresql.org/docs/8.3/static/sql-altertable.html [2] http://www.postgresql.org/docs/8.3/static/sql-vacuum.html [3] http://www.postgresql.org/docs/8.3/static/datatype-oid.html [4] http://www.postgresql.org/docs/8.3/static/explicit-locking.html [5] http://www.postgresql.org/docs/8.3/static/sql-select.html -- Euler Taveira de Oliveira http://www.timbira.com/ _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
