(...)
No que diz respeito a versão do PostgreSQL e PostGIS não vemos problemas.
Mas não entendemos o que levaria ao produto restringir o SO do SGBD em
Windows, Red Hat e SUSE Enterprise se o servidor do SGBD não é
compartilhado com o servidor do produto.
E vocês têm razão.
Atualmente temos diversos servidores PostgreSQL rodando no CentOS sem
qualquer problema com diversas aplicações (produtos open source ou
aplicações desenvolvidas internamente usando desde Java a .Net).
Eu também, assim como muitos aqui na lista.
As minhas perguntas para a comunidade são:
1) Alguém conhece (ou consegue imaginar) alguma justificativa técnica
para que um produto estabeleça restrições na camada subjacente do SGBD
(ou seja o SO)?
Tecnicamente falando: *zero*
As empresas que fazem isso (limitar S.O.) o fazem por motivos geralmente
de suporte (por exemplo, ao telefone, um técnico diz pra mudar o
parâmetro x no arquivo y do diretório z). No seu caso, CentOS e Redhat
são idênticos nesse ponto.
Aí, quando se fala em CentOS, vem a questão contrato: se houver um
problema de desempenho, poderiam dizer que a culpa é sua por não usar um
"S.O. homologado".
2) Sendo o PostgreSQL um software livre, pode um software proprietário
fazer este tipo de restrição?
Tecnicamente isso significa que o fornecedor não merece confiança.
Contratualmente, eles estão na média do mercado, ou seja, medíocres. Em
geral é assim no mundo proprietário.
Mas sim, podem, não tem nenhuma relação com licenças livres aí. E a
licença do PostgreSQL é extremamente simples e não restritiva.
Agradeço antecipadamente as colaborações.
Desculpe a sinceridade.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
