Re: [pgbr-geral] spclocation
Pois é, macaco velho fica confiante demais no galho... hehehe. Mas o ambiente é controlado, dá pra arriscar. Os benefícios da nova versão me chamaram a atenção. A rotina em questão é de comparer, vou ter dar outro jeito (como diff do metadado, por exemplo). - Mensagem original - De: Euler Taveira eu...@timbira.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Cc: Enviadas: Quarta-feira, 19 de Setembro de 2012 21:25 Assunto: Re: [pgbr-geral] spclocation On 19-09-2012 18:24, Jean Domingues wrote: Eu fiz uma nova instalação do servidor, compilei, configurei backup (por log). Pra reverter agora vai dar trabalho. Faltou fazer o principal: homologação. Como você coloca algo em produção sem saber se ao menos todas as suas rotinas (processos) antigas funcionam? -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] spclocation
Pois é, macaco velho fica confiante demais no galho... hehehe. Mas o ambiente é controlado, dá pra arriscar. Os benefícios da nova versão me chamaram a atenção. A rotina em questão é de comparer, vou ter dar outro jeito (como diff do metadado, por exemplo). Como já disseram existe o pgdiff[1], concordo que a ferramenta da EMS é bem mais completa, mas o pgdiff pode atender bem a maioria dos casos. Uma pena estar descontinuado. [1] = http://pgdiff.sourceforge.net/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] spclocation
A EMS disse que só vai liberar atualização para 9.2 em outubro. Que coisa, não? O pgdiff atende o 9.2? Você usa? De: Vinicius Santos vinicius.santos.li...@gmail.com Para: Jean Domingues ejdom...@yahoo.com.br; Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Quinta-feira, 20 de Setembro de 2012 8:31 Assunto: Re: [pgbr-geral] spclocation Pois é, macaco velho fica confiante demais no galho... hehehe. Mas o ambiente é controlado, dá pra arriscar. Os benefícios da nova versão me chamaram a atenção. A rotina em questão é de comparer, vou ter dar outro jeito (como diff do metadado, por exemplo). Como já disseram existe o pgdiff[1], concordo que a ferramenta da EMS é bem mais completa, mas o pgdiff pode atender bem a maioria dos casos. Uma pena estar descontinuado. [1] = http://pgdiff.sourceforge.net/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] spclocation
A EMS disse que só vai liberar atualização para 9.2 em outubro. Que coisa, não? O pgdiff atende o 9.2? Você usa? O pgdiff trabalha de maneira diferente da ferramenta da EMS, é como o diff do GIT ou SVN ,da uma olhada na documentação para mais detalhes, é realmente muito simples. Eu uso sim, e pra mim funciona bem. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] spclocation
Não, mas já estou testando. Valeu. - Mensagem original - De: Bruno Silva bemanuel...@gmail.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Cc: Enviadas: Quinta-feira, 20 de Setembro de 2012 9:17 Assunto: Re: [pgbr-geral] spclocation Eu uso muito o apgdiff e me atende bem. Você já o usou? Bruno E. A. Silva. Analista de Sistemas. 2012/9/20 Matheus de Oliveira matioli.math...@gmail.com: 2012/9/20 Vinicius Santos vinicius.santos.li...@gmail.com A EMS disse que só vai liberar atualização para 9.2 em outubro. Que coisa, não? O pgdiff atende o 9.2? Você usa? O pgdiff trabalha de maneira diferente da ferramenta da EMS, é como o diff do GIT ou SVN ,da uma olhada na documentação para mais detalhes, é realmente muito simples. Eu uso sim, e pra mim funciona bem. Tem também o apgdiff [1] que está não está descontinuado... [1] http://apgdiff.startnet.biz/ Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados PostgreSQL Dextra Sistemas - MPS.Br nível F! www.dextra.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] como trasformar usuario em cliemte com heranca
Bom dia pessoal!!
estou usando postgresql 9.2.
Tenho a seguinte estrutura:
create table usuario (
email varchar(100) not null primary key,
senha varchar(255) not null
);
create table cliente (
nome varchar(100) not null,
cpf text not null
) inherits (usuario);
tenho um usuario:
moi=# insert into usuario (email, senha) values ('u...@gmail.com',
'123456');
INSERT 0 1
quero transformar este usuario em cliente. so que a query abaixo nao
funciona:
moi=# update cliente set nome = 'Usuario da Silva', cpf = 'xx' where email
= 'u...@gmail.com';
UPDATE 0
Alguem tem alguma ideia de como resolver este tipo de situacao?
Obrigado!!
--
Moisés P. Sena
(Analista e desenvolvedor de sistemas WEB e mobile)
http://www.moisespsena.com
http://linux.moisespsena.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] como trasformar usuario em cliemte com heranca
Em 20 de setembro de 2012 10:23, Moisés P. Sena
moisesps...@gmail.com escreveu:
(.)
create table usuario (
email varchar(100) not null primary key,
senha varchar(255) not null
);
create table cliente (
nome varchar(100) not null,
cpf text not null
) inherits (usuario);
tenho um usuario:
moi=# insert into usuario (email, senha) values ('u...@gmail.com',
'123456');
INSERT 0 1
quero transformar este usuario em cliente.
(...)
Não ficou claro pra mim sua dúvida. Você tem registros na tabela
usuario que não estão em cliente e queria que os usuário estivessem em
cliente ou uma forma de convertê-los?
Pelo caso que você mostrou dá a entender também que a forma que a
herança foi trabalhada está incorreta.
Na herança que você passou cliente é um tipo de usuário
(especialização), neste caso você deveria inserir somente registros em
cliente que automaticamente apareceria em usuario. Se no insert que
você fez em usuario você tivesse feito em cliente, creio que seu
problema estaria resolvido:
insert into cliente values('u...@gmail.com', '123456', 'nome1', '12345678901');
--
Marcone Peres - DBA
http://www.linkedin.com/in/marconeperes
@marconeperes
(61) 8146-0028
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] como trasformar usuario em cliemte com heranca
2012/9/20 Moisés P. Sena moisesps...@gmail.com: ) inherits (usuario); Evite. O ideal é uma simples chave estrangeira. Herança introduz mais problemas, como esse… o modelo relacional já é completo e simples. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Google F1, ‘o retorno’
2012/9/18 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org: Interessantemente, parece que o F1 é construído sobre o Spanner http://research.google.com/archive/spanner.html, que parece ser mais relacional que o SQL, requerendo que toda tabela tenha uma chave — ou seja, trabalha com relações de fato. Alguém chegou a analisar o aspecto relacional do Spanner? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Banco Postgres Multi Empresa
Bom dia Pessoal! Minha primeira participação na lista! Hoje uso o postgres 9.0 na empresa que trabalho...agora surgiu a necessidade de tornar o sistema multi empresa. Alguem poderia me dar algumas opnioes? Usar schemas? Usar tabelas com códigoEmpresa Alguem poderia comentar? Rodrigo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Carregar biblioteca pgxml.so
Tem certeza? Não esqueceste de um make make install não? Por favor, execute o seguinte e poste o resultado: /path/to/postgresql/bin/pg_config --configure Com isso dá pra ver como realmente foi chamado o ./configure. -- Matheus de Oliveira Analista de Banco de Dados PostgreSQL Dextra Sistemas - MPS.Br nível F! www.dextra.com.br (http://www.dextra.com.br/) ~S /usr/local/pgsql-9.2-xml/bin/pg_config --configure'--with-libxml' '--with-libxslt' '--exec-prefix=/usr/local/pgsql-9.2-xml/' '--prefix=/usr/local/pgsql-9.2-xml/' Aparentemente a configuração está normal. Existe alguma configuração extraordinária que deve ser feita ? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco Postgres Multi Empresa
Em 20-09-2012 10:52, Rodrigo escreveu: Bom dia Pessoal! Minha primeira participação na lista! Hoje uso o postgres 9.0 na empresa que trabalho...agora surgiu a necessidade de tornar o sistema multi empresa. Alguem poderia me dar algumas opnioes? Usar schemas? Usar tabelas com códigoEmpresa Ambas as situações resolvem seu problema. O uso de múltiplos esquemas pode evitar que você tenha que fazer novo código na aplicação, enquanto que o uso de campo código pode ter de fazer que você modifique toda a sua aplicação. A opção é totalmente sua preferência. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco Postgres Multi Empresa
2012/9/20 Rodrigo rodrigo.ina...@alcafoods.com: Hoje uso o postgres 9.0 na empresa que trabalho...agora surgiu a necessidade de tornar o sistema multi empresa. Alguem poderia me dar algumas opnioes? Usar schemas? Cada empresa fica relativamente isolada e a programação não muda nada, mas é mais complicado de administrar e de cruzar informações. Nessa opção, é conveniente criar um esquema para as informações ‘de referência’, cadastros centrais, como UFs, CEPs c. Usar tabelas com códigoEmpresa Prefiro… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] como trasformar usuario em cliemte com heranca
Em 20 de setembro de 2012 10:39, Marcone marconepe...@gmail.com escreveu:
Em 20 de setembro de 2012 10:23, Moisés P. Sena
moisesps...@gmail.com escreveu:
(.)
create table usuario (
email varchar(100) not null primary key,
senha varchar(255) not null
);
create table cliente (
nome varchar(100) not null,
cpf text not null
) inherits (usuario);
tenho um usuario:
moi=# insert into usuario (email, senha) values ('u...@gmail.com',
'123456');
INSERT 0 1
quero transformar este usuario em cliente.
(...)
Não ficou claro pra mim sua dúvida. Você tem registros na tabela
usuario que não estão em cliente e queria que os usuário estivessem em
cliente ou uma forma de convertê-los?
Exatamente, quero convertê-los..
--
Marcone Peres - DBA
http://www.linkedin.com/in/marconeperes
@marconeperes
(61) 8146-0028
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
Moisés P. Sena
(Analista e desenvolvedor de sistemas WEB e mobile)
http://www.moisespsena.com
http://linux.moisespsena.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] spclocation
Bruno, tentei, mas ta dando o seguinte erro: C:\Temp\SQLComparer\Program Files (x86)\Java\jre6\bin\java.exe -jar apgdiff-2 .3.jar source.sql target.sql sync.sql Exception in thread main java.lang.StringIndexOutOfBoundsException: String ind ex out of range: 91 at java.lang.String.substring(Unknown Source) at cz.startnet.utils.pgdiff.parsers.Parser.parseString(Parser.java:267) at cz.startnet.utils.pgdiff.parsers.CommentParser.getComment(CommentPars er.java:356) at cz.startnet.utils.pgdiff.parsers.CommentParser.parseColumn(CommentPar ser.java:272) at cz.startnet.utils.pgdiff.parsers.CommentParser.parse(CommentParser.ja va:46) at cz.startnet.utils.pgdiff.loader.PgDumpLoader.loadDatabaseSchema(PgDum pLoader.java:202) at cz.startnet.utils.pgdiff.loader.PgDumpLoader.loadDatabaseSchema(PgDum pLoader.java:239) at cz.startnet.utils.pgdiff.PgDiff.createDiff(PgDiff.java:36) at cz.startnet.utils.pgdiff.Main.main(Main.java:45) Não, mas já estou testando. Valeu. Eu uso muito o apgdiff e me atende bem. Você já o usou? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] como trasformar usuario em cliemte com heranca
Em 20 de setembro de 2012 10:44, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/9/20 Moisés P. Sena moisesps...@gmail.com: ) inherits (usuario); Evite. O ideal é uma simples chave estrangeira. Herança introduz mais problemas, como esse… o modelo relacional já é completo e simples. Por que este é um problema (e nao apenas um caso)??? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Moisés P. Sena (Analista e desenvolvedor de sistemas WEB e mobile) http://www.moisespsena.com http://linux.moisespsena.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] como trasformar usuario em cliemte com heranca
Em 20-09-2012 10:23, Moisés P. Sena escreveu:
Bom dia pessoal!!
estou usando postgresql 9.2.
Tenho a seguinte estrutura:
create table usuario (
email varchar(100) not null primary key,
senha varchar(255) not null
);
create table cliente (
nome varchar(100) not null,
cpf text not null
) inherits (usuario);
tenho um usuario:
moi=# insert into usuario (email, senha) values ('u...@gmail.com
mailto:u...@gmail.com', '123456');
INSERT 0 1
quero transformar este usuario em cliente. so que a query abaixo nao
funciona:
moi=# update cliente set nome = 'Usuario da Silva', cpf = 'xx' where
email = 'u...@gmail.com mailto:u...@gmail.com';
UPDATE 0
Muita gente respondeu mas ninguém explicou o fato.
Note que seu INSERT foi na tabela usuario.
INSERTs não são propagados para as tabelas herdeiras.
O seu UPDATE deveria ser feito sobre a tabela pai.
Note que o UPDATE não moverá a linha para a tabela herdeira também.
Você terá de escrever uma função/gatilho para resolver isso ou fazer
todos os passos por fora.
[]s
__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] como trasformar usuario em cliemte com heranca
Em 20 de setembro de 2012 11:04, Moisés P. Sena moisesps...@gmail.com escreveu: () Exatamente, quero convertê-los.. Na forma que você passou não vai ter como por alguns motivo simples: 1 - Como carregar os demais dados de cliente (nome e CPF), você teria um de - para? 2 - Com a herança, mesmo com resposta positiva para [1], os registros seriam duplicados em usuario. Minhas sugestões: I - Se você optar por manter a herança (leve em conta o que o DUTRA falou) a saída que eu vejo é um tabalho manual de remoção dos usuarios e recadastro dos clientes. Isto pode ser bastante trabalhoso e você vai correr riscos de quebra de integridade. II - Se você retirar a herança, crie uma coluna, faça um update e crie uma chave estrangeira em usuario com cliente. -- Marcone Peres - DBA http://www.linkedin.com/in/marconeperes @marconeperes (61) 8146-0028 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] spclocation
Já achei a resposta. https://github.com/fordfrog/apgdiff/issues/69 - Mensagem original - De: Jean Domingues ejdom...@yahoo.com.br Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Cc: Enviadas: Quinta-feira, 20 de Setembro de 2012 11:13 Assunto: Re: [pgbr-geral] spclocation Bruno, tentei, mas ta dando o seguinte erro: C:\Temp\SQLComparer\Program Files (x86)\Java\jre6\bin\java.exe -jar apgdiff-2 .3.jar source.sql target.sql sync.sql Exception in thread main java.lang.StringIndexOutOfBoundsException: String ind ex out of range: 91 at java.lang.String.substring(Unknown Source) at cz.startnet.utils.pgdiff.parsers.Parser.parseString(Parser.java:267) at cz.startnet.utils.pgdiff.parsers.CommentParser.getComment(CommentPars er.java:356) at cz.startnet.utils.pgdiff.parsers.CommentParser.parseColumn(CommentPar ser.java:272) at cz.startnet.utils.pgdiff.parsers.CommentParser.parse(CommentParser.ja va:46) at cz.startnet.utils.pgdiff.loader.PgDumpLoader.loadDatabaseSchema(PgDum pLoader.java:202) at cz.startnet.utils.pgdiff.loader.PgDumpLoader.loadDatabaseSchema(PgDum pLoader.java:239) at cz.startnet.utils.pgdiff.PgDiff.createDiff(PgDiff.java:36) at cz.startnet.utils.pgdiff.Main.main(Main.java:45) Não, mas já estou testando. Valeu. Eu uso muito o apgdiff e me atende bem. Você já o usou? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco Postgres Multi Empresa
Posso sugerir também, a criação de cluster´s, assim cada empresa teria seu proprio postgres, ficando cada uma com sua própria configuração/otimização e porta. Isso facilita também, caso haja a necessidade de parar uma das empresas, sem afetar as outras. Utilizamos aqui, a seguinte configuração do diretório de dados. Isso em storage. /pgproducao/9.1/empresax /pgproducao/9.1/empresay Att. Em 20 de setembro de 2012 10:59, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/9/20 Rodrigo rodrigo.ina...@alcafoods.com: Hoje uso o postgres 9.0 na empresa que trabalho...agora surgiu a necessidade de tornar o sistema multi empresa. Alguem poderia me dar algumas opnioes? Usar schemas? Cada empresa fica relativamente isolada e a programação não muda nada, mas é mais complicado de administrar e de cruzar informações. Nessa opção, é conveniente criar um esquema para as informações ‘de referência’, cadastros centrais, como UFs, CEPs c. Usar tabelas com códigoEmpresa Prefiro… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] como trasformar usuario em cliemte com heranca
2012/9/20 Moisés P. Sena moisesps...@gmail.com: Em 20 de setembro de 2012 10:44, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/9/20 Moisés P. Sena moisesps...@gmail.com: ) inherits (usuario); Evite. O ideal é uma simples chave estrangeira. Herança introduz mais problemas, como esse… o modelo relacional já é completo e simples. Por que este é um problema (e nao apenas um caso)??? Por problemas como o teu… o modelo relacional é simples e transparente; herança viola o princípio da informação (‘toda informação é representada exclusivamente como valores explícitos de atributos em tuplas de relações’, ou algo assim), e torna o modelo mais ‘opaco’, quer dizer, mais difícil de entender, guardar e manipular. Hoje, herança praticamente só é usada para particionamento. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco Postgres Multi Empresa
2012/9/20 mauro fonseca mfons...@pbh.gov.br: Posso sugerir também, a criação de cluster´s, assim cada empresa teria seu proprio postgres, ficando cada uma com sua própria configuração/otimização e porta. Mas aí não dá para compartilhar ou cruzar dados tão facilmente. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] como trasformar usuario em cliemte com heranca
Em 20 de setembro de 2012 10:44, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: Evite. O ideal é uma simples chave estrangeira. Herança introduz mais problemas, como esse… o modelo relacional já é completo e simples. Ok, posso usar sim. Em 20 de setembro de 2012 11:23, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: Você terá de escrever uma função/gatilho para resolver isso ou fazer todos os passos por fora. Nao legal esta idéia. nao para o meu caso. Em 20 de setembro de 2012 11:25, Marcone marconepe...@gmail.com escreveu: Na forma que você passou não vai ter como por alguns motivo simples: 1 - Como carregar os demais dados de cliente (nome e CPF), você teria um de - para? 2 - Com a herança, mesmo com resposta positiva para [1], os registros seriam duplicados em usuario. Minhas sugestões: I - Se você optar por manter a herança (leve em conta o que o DUTRA falou) a saída que eu vejo é um tabalho manual de remoção dos usuarios e recadastro dos clientes. Isto pode ser bastante trabalhoso e você vai correr riscos de quebra de integridade. II - Se você retirar a herança, crie uma coluna, faça um update e crie uma chave estrangeira em usuario com cliente. vou preferir uma chave estrangeira. Em 20 de setembro de 2012 11:34, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: Por problemas como o teu… o modelo relacional é simples e transparente; herança viola o princípio da informação (‘toda informação é representada exclusivamente como valores explícitos de atributos em tuplas de relações’, ou algo assim), e torna o modelo mais ‘opaco’, quer dizer, mais difícil de entender, guardar e manipular. Hoje, herança praticamente só é usada para particionamento. Entendi. Entao ESQUECO heranca para heranca, e uso apenas relacionamento para heranca, por causo dos motivos citados acima. Obrigado a todos, foi muito esclarecedor. -- Moisés P. Sena (Analista e desenvolvedor de sistemas WEB e mobile) http://www.moisespsena.com http://linux.moisespsena.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] como trasformar usuario em cliemte com heranca
2012/9/20 Moisés P. Sena moisesps...@gmail.com: Entendi. Entao ESQUECO heranca para heranca, e uso apenas relacionamento para heranca, por causo dos motivos citados acima. Exato. Só repare que ‘relacionamento’ não é um termo relacional, mas de DERs; o termo seria ‘chave estrangeira’, ou ‘restrição de integridade referencial’, ou simplesmente referência. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] como trasformar usuario em cliemte com heranca
Em 20 de setembro de 2012 11:43, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/9/20 Moisés P. Sena moisesps...@gmail.com: Entendi. Entao ESQUECO heranca para heranca, e uso apenas relacionamento para heranca, por causo dos motivos citados acima. Exato. Só repare que ‘relacionamento’ não é um termo relacional, mas de DERs; o termo seria ‘chave estrangeira’, ou ‘restrição de integridade referencial’, ou simplesmente referência. Obrigado pela dica, vou lembrar disso. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Moisés P. Sena (Analista e desenvolvedor de sistemas WEB e mobile) http://www.moisespsena.com http://linux.moisespsena.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Banco Postgres Multi Empresa
On 20-09-2012 11:28, mauro fonseca wrote: Posso sugerir também, a criação de cluster´s, assim cada empresa teria seu proprio postgres, ficando cada uma com sua própria configuração/otimização e porta. Isso facilita também, caso haja a necessidade de parar uma das empresas, sem afetar as outras. Utilizamos aqui, a seguinte configuração do diretório de dados. Isso em storage. /pgproducao/9.1/empresax /pgproducao/9.1/empresay Criar vários clusters só aumenta o uso de recursos do hardware em relação a um cluster com vários bancos de dados (cada porta terá vários processo em segundo plano). Só utilize esse modelo se você precisa de isolamento total de acesso aos dados. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] como trasformar usuario em cliemte com heranca
Em 20 de setembro de 2012 11:49, Matheus de Oliveira
matioli.math...@gmail.com escreveu:
2012/9/20 Moisés P. Sena moisesps...@gmail.com
Bom dia pessoal!!
estou usando postgresql 9.2.
Tenho a seguinte estrutura:
create table usuario (
email varchar(100) not null primary key,
senha varchar(255) not null
);
create table cliente (
nome varchar(100) not null,
cpf text not null
) inherits (usuario);
tenho um usuario:
moi=# insert into usuario (email, senha) values ('u...@gmail.com',
'123456');
INSERT 0 1
quero transformar este usuario em cliente. so que a query abaixo nao
funciona:
moi=# update cliente set nome = 'Usuario da Silva', cpf = 'xx' where
email = 'u...@gmail.com';
UPDATE 0
Alguem tem alguma ideia de como resolver este tipo de situacao?
O pessoal já disse, herança não é bom (geralmente), mas fiquei com vontade
de postar uma solução caso queira usar:
WITH del AS (
DELETE FROM usuario WHERE email = 'u...@gmail.com'
RETURNING *
)
INSERT INTO cliente (nome, cpf, email, senha)
SELECT 'Usuário da Silva', 'XX', email, senha FROM del;
Interessante
obrigado!
De qualquer maneira eu também concordo que heranças só atrapalham em casos
como esse. Mas veja que é possível uma conversão forçada (mas ainda
podendo levar à problemas de integridade).
Atenciosamente,
--
Matheus de Oliveira
Analista de Banco de Dados PostgreSQL
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
Moisés P. Sena
(Analista e desenvolvedor de sistemas WEB e mobile)
http://www.moisespsena.com
http://linux.moisespsena.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: Banco Postgres Multi Empresa
E em relação os cruzamentos de informações serem complexas não tem tanto problema...pois o tempo que vou economizar com código compensará...e as consultas entre os schemas? Isso pode pessar o sistema? Rodrigo -Mensagem original- De: pgbr-geral-boun...@listas.postgresql.org.br [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Guimarães Faria Corcete DUTRA, Leandro Enviada em: quinta-feira, 20 de setembro de 2012 10:59 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] Banco Postgres Multi Empresa 2012/9/20 Rodrigo rodrigo.ina...@alcafoods.com: Hoje uso o postgres 9.0 na empresa que trabalho...agora surgiu a necessidade de tornar o sistema multi empresa. Alguem poderia me dar algumas opnioes? Usar schemas? Cada empresa fica relativamente isolada e a programação não muda nada, mas é mais complicado de administrar e de cruzar informações. Nessa opção, é conveniente criar um esquema para as informações ‘de referência’, cadastros centrais, como UFs, CEPs c. Usar tabelas com códigoEmpresa Prefiro… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: Banco Postgres Multi Empresa
2012/9/20 Rodrigo rodrigo.ina...@alcafoods.com: E em relação os cruzamentos de informações serem complexas não tem tanto problema...pois o tempo que vou economizar com código compensará... A curto prazo, sim, mas a longo… e as consultas entre os schemas? Isso pode pessar o sistema? Não pessar nem pesar, mas pode ficar inviável fazer uma pesquisa sobre ‘n’ tabelas… principalmente consultas ad hoc. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Trigger Data_Cadastro e Data_Alteracao
Blz pessoal, Sou novo com postgres e estou querendo tentar resolver um problema que estou tendo. Em todas as tabelas do meu sistema tenho dois campos (Data_Cadastro, Data_Alteracao), quero ver com vocês se tem como criar um trigger que todos poderiam utilizar, a função que ela iria executar é no Insert inserir a data de cadastro atual, e data_alteracao toda vez que tiver alteração ela atualizar a data de alteração. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: RES: Banco Postgres Multi Empresa
Entao! O mais trabalhoso que seria colocar o campo codempresa em todas as tabelas se tornaria o mais rápido? Rodrigo -Mensagem original- De: pgbr-geral-boun...@listas.postgresql.org.br [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Guimarães Faria Corcete DUTRA, Leandro Enviada em: quinta-feira, 20 de setembro de 2012 15:28 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] RES: Banco Postgres Multi Empresa 2012/9/20 Rodrigo rodrigo.ina...@alcafoods.com: E em relação os cruzamentos de informações serem complexas não tem tanto problema...pois o tempo que vou economizar com código compensará... A curto prazo, sim, mas a longo… e as consultas entre os schemas? Isso pode pessar o sistema? Não pessar nem pesar, mas pode ficar inviável fazer uma pesquisa sobre ‘n’ tabelas… principalmente consultas ad hoc. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Trigger Data_Cadastro e Data_Alteração
Pessoal vlw ai mas acho que consegui criar o código ficou assim agora so adicionar em todas as tabelas create function dtcad_gatilho() returns trigger as $dtcad_gatilho$ begin new.data_cadastro := 'now'; return new; end; $dtcad_gatilho$ language plpgsql; ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: RES: Banco Postgres Multi Empresa
2012/9/20 Rodrigo rodrigo.ina...@alcafoods.com: Entao! O mais trabalhoso que seria colocar o campo codempresa em todas as tabelas se tornaria o mais rápido? Não entendi a frase. A inviabilidade não está em velocidade, mas no fato de ter, para consultas ad hoc, de enumerar tabelas de vários esquemas para obter a mesma informação. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: RES: Banco Postgres Multi Empresa
Se a aplicação realmente for 100% separada e nunca vai haver consulta em dados das duas empresas, pode-se criar bases separadas no mesmo cluster e cada empresa conecta em uma base. Se por ventura o sistema ter que ser multiempresa onde vai existir informações comuns entre elas, não vejo melhor opção que criar realmente um campo nas tabelas para você informar a que empresa o registro se refere. Att. Rieg - Original Message - From: Rodrigo rodrigo.ina...@alcafoods.com To: 'Comunidade PostgreSQL Brasileira' pgbr-geral@listas.postgresql.org.br Sent: Thursday, September 20, 2012 4:18 PM Subject: [pgbr-geral] RES: RES: Banco Postgres Multi Empresa Entao! O mais trabalhoso que seria colocar o campo codempresa em todas as tabelas se tornaria o mais rápido? Rodrigo -Mensagem original- De: pgbr-geral-boun...@listas.postgresql.org.br [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Guimarães Faria Corcete DUTRA, Leandro Enviada em: quinta-feira, 20 de setembro de 2012 15:28 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] RES: Banco Postgres Multi Empresa 2012/9/20 Rodrigo rodrigo.ina...@alcafoods.com: E em relação os cruzamentos de informações serem complexas não tem tanto problema...pois o tempo que vou economizar com código compensará... A curto prazo, sim, mas a longo… e as consultas entre os schemas? Isso pode pessar o sistema? Não pessar nem pesar, mas pode ficar inviável fazer uma pesquisa sobre ‘n’ tabelas… principalmente consultas ad hoc. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: RES: RES: Banco Postgres Multi Empresa
Assim! Estou observando que estruturar o banco mult empresa com vários schemas, no futuro pode complicar a performance as consultas.essa forma de schemas para mim hoje não precisaria eu mudar praticamente nada no meu códigomas parece que vai agir diretamente no rendimento geral do sistema... A outra opção que seria mais trabalhosa. Ou seja, ir em cada tabela, consulta, relatório, insert, update e tale adicionar o campo codemp. Seria trabalho mas não influenciaria na performance e nem em muitas alterações nas consultas Certo? Rodrigo -Mensagem original- De: pgbr-geral-boun...@listas.postgresql.org.br [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Guimarães Faria Corcete DUTRA, Leandro Enviada em: quinta-feira, 20 de setembro de 2012 16:26 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] RES: RES: Banco Postgres Multi Empresa 2012/9/20 Rodrigo rodrigo.ina...@alcafoods.com: Entao! O mais trabalhoso que seria colocar o campo codempresa em todas as tabelas se tornaria o mais rápido? Não entendi a frase. A inviabilidade não está em velocidade, mas no fato de ter, para consultas ad hoc, de enumerar tabelas de vários esquemas para obter a mesma informação. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: RES: RES: Banco Postgres Multi Empresa
2012/9/20 Rodrigo rodrigo.ina...@alcafoods.com: Assim! O que isso quer dizer? Estou observando que estruturar o banco mult empresa com vários schemas, no futuro pode complicar a performance as consultas... Não necessariamente, o problema maior é a usabilidade. O que ainda é muito importante. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: RES: RES: Banco Postgres Multi Empresa
2012/9/20 Rodrigo rodrigo.ina...@alcafoods.com Assim! Estou observando que estruturar o banco mult empresa com vários schemas, no futuro pode complicar a performance as consultas.essa forma de schemas para mim hoje não precisaria eu mudar praticamente nada no meu código Realmente, e dependendo do caso, seria bom criar um usuário para cada esquema, com permissões apenas para o mesmo por questão de segurança (isso se a aplicação for desktop ou o servidor for no cliente), assim você também pode atrelar o search_path ao usuário (role). Por outro lado isso inviabiliza o uso de pool de conexões compartilhado entre os usuários... Por isso vai depender de uma análise do cenário. mas parece que vai agir diretamente no rendimento geral do sistema... Por que acha isso? De certa forma pode-se até pensar que melhora, pois as tabelas vão estar mais leves, o que também pode-se alcançar facilmente com particionamento (se usar o modelo de campo com código). A outra opção que seria mais trabalhosa. Ou seja, ir em cada tabela, consulta, relatório, insert, update e tale adicionar o campo codemp. Seria trabalho mas não influenciaria na performance e nem em muitas alterações nas consultas Você tem que analisar melhor o quão dificil vai ser isso. Outra coisa que tens de analisar, você vai ter muito relatório/consultas que pegam dados de mais de uma empresa de uma só vez? Se não for o caso, esse trabalho todo talvez não compense e o uso de esquemas seja mais simples e efetivo. Além do que, para os casos com consultas em vários você pode criar views com diversos unions (o que teria a mesma performance que consultas em uma tabela particionada). Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados PostgreSQL Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] problemas com: CREATE EXTENSION postgis;
sALLdações. Ambiente: Debian 6 / PostgreSQL 9.1 / PostGis 1.5 Estou recebendo a seguinte mensagem de erro ao tentar executar um CREATE EXTENSION : --* Erro de SQL:* ERROR: could not open extension control file /usr/share/postgresql/9.1/extension/postgis.control: No such file or directory* Indicação de entrada :* CREATE EXTENSION postgis; --- Observei o diretório /usr/share/postgresql/9.1/extension/ e realmente não há nada lá que se relacione com postgis. Para efeito de informação, para alguém que venha a me ajudar a encontrar a solução deste problema, encontrei alguns problemas na execução de um certo roteiro de instalação do POSTGIS. A seguir, vou descrever minimamente, algo que empreendi desse roteiro. 1 - instalação Tenho os seguintes pacotes instalados: ii postgresql 9.1+122ubuntu1 object-relational SQL database (supported version) ii postgresql-9.1 9.1.4-0ubuntu11.10 object-relational SQL database, version 9.1 server ii postgresql-9.1-debversion 1.0.6-1ubuntu1 Debian version number type for PostgreSQL ii postgresql-9.1-ip4r 1.05-0.1 IPv4 and IPv4 range index types for PostgreSQL 9.1 ii postgresql-9.1-pljava-gcj 1.4.2-4ubuntu1 Java procedural language for PostgreSQL 9.1 ii postgresql-9.1-pllua1:0.3.2-4 Lua procedural language for PostgreSQL 9.1 ii postgresql-9.1-plsh 1.3-5 PL/sh procedural language for PostgreSQL 9.1 ii postgresql-9.1-postgis 1.5.3-1ubuntu0.1 Geographic objects support for PostgreSQL 9.1 ii postgresql-client 9.1+122ubuntu1 front-end programs for PostgreSQL (supported version) ii postgresql-client-9.1 9.1.4-0ubuntu11.10 front-end programs for PostgreSQL 9.1 ii postgresql-client-common122ubuntu1 manager for multiple PostgreSQL client versions ii postgresql-common 122ubuntu1 PostgreSQL database-cluster manager ii postgresql-contrib 9.1+122ubuntu1 additional facilities for PostgreSQL (supported version) ii postgresql-contrib-9.1 9.1.4-0ubuntu11.10 additional facilities for PostgreSQL ii postgresql-doc 9.1+122ubuntu1 documentation for the PostgreSQL database management system ii postgresql-doc-9.1 9.1.4-0ubuntu11.10 documentation for the PostgreSQL database management system ii postgis 1.5.3-1ubuntu0.1 Geographic objects support for PostgreSQL -- common files ii postgresql-9.1-postgis 1.5.3-1ubuntu0.1 Geographic objects support for PostgreSQL 9.1 2 - configuração inicial 2.1 - no diretorio: /usr/share/postgresql/9.1/contrib e executei: psql -f postgis_comments.sql -d meu_banco - *ok* 2.2 - no diretorio: /usr/share/postgresql/9.1/contrib/postgis-1.5 executei: $ psql -f postgis.sql -d meu_banco - *que apresentou o seguinte resultado:* psql:postgis.sql:82: ERROR: type spheroid already exists psql:postgis.sql:92: ERROR: current transaction is aborted, commands ignored until end of transaction block psql:postgis.sql:98: ERROR: current transaction is aborted, commands ignored until end of transaction block psql:postgis.sql:104: ERROR: current transaction is aborted, commands ignored until end of transaction block psql:postgis.sql:110: ERROR: current transaction is aborted, commands ignored until end of transaction block ... psql:postgis.sql:7741: ERROR: current transaction is aborted, commands ignored until end of transaction block psql:postgis.sql:7746: ERROR: current transaction is aborted, commands ignored until end of transaction block ROLLBACK DROP AGGREGATE DROP AGGREGATE DROP AGGREGATE DROP AGGREGATE DROP FUNCTION DROP FUNCTION ... 2.3 - no diretorio: /usr/share/postgresql/9.1/contrib/postgis-1.5 executei: $ psql -f spatial_ref_sys.sql -d meu_banco) - *que também apresentou um monte de erros* Então, é isso. Aqui encerraram-se minhas tentativas. Resta-me (portanto) pedir-lhes ajuda. Será que a execução sem problemas dos scripts (que me disseram que seriam) de instalação / configuração inicial do PostGis é a causa da falha na tentativa de Criar Extensão ? Grato (antecipadamente): Marcos Nobre ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Trigger Data_Cadastro e Data_Alteracao
2012/9/20 Éverton Bueno Lima everton_bueno_l...@hotmail.com Blz pessoal, ** ** Sou novo com postgres e estou querendo tentar resolver um problema que estou tendo. Em todas as tabelas do meu sistema tenho dois campos (Data_Cadastro, Data_Alteracao), quero ver com vocês se tem como criar um trigger que todos poderiam utilizar, a função que ela iria executar é no Insert inserir a data de cadastro atual, e data_alteracao toda vez que tiver alteração ela atualizar a data de alteração. ** ** ** É só criar uma função mais genérica: CREATE OR REPLACE FUNCTION set_data_cadalt() RETURNS TRIGGER LANGUAGE plpgsql VOLATILE AS $$ BEGIN IF (TG_OP == 'INSERT') THEN new.data_cadastro = now(); ELSE new.data_alteracao = now(); END IF; RETURN new; END; $$; E, criar as triggers para cada tabela que tenha data_cadastro e data_alteracao: CREATE TRIGGER tg_set_data_cadalt BEFORE INSERT OR UPDATE ON *sua_tabela* **FOR EACH ROW EXECUTE PROCEDURE set_data_cadal(); Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados PostgreSQL Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] problemas com: CREATE EXTENSION postgis;
2012/9/20 Marcos Aurelio Nobre marcono...@gmail.com: Estou recebendo a seguinte mensagem de erro ao tentar executar um CREATE EXTENSION : O Postgis só dá suporte ao comando CREATE EXTENSION à aprtir da versão 2.0 [1] (.) 2 - configuração inicial 2.1 - no diretorio: /usr/share/postgresql/9.1/contrib e executei: psql -f postgis_comments.sql -d meu_banco - ok 2.2 - no diretorio: /usr/share/postgresql/9.1/contrib/postgis-1.5 executei: $ psql -f postgis.sql -d meu_banco - que apresentou o seguinte resultado: psql:postgis.sql:82: ERROR: type spheroid already exists psql:postgis.sql:92: ERROR: current transaction is aborted, commands ignored until end of transaction block psql:postgis.sql:98: ERROR: current transaction is aborted, commands ignored until end of transaction block psql:postgis.sql:104: ERROR: current transaction is aborted, commands ignored until end of transaction block psql:postgis.sql:110: ERROR: current transaction is aborted, commands ignored until end of transaction block (...) A sequencia de execução dos scripts não foi obedecida. A ordem correta é [2]: psql -d [yourdatabase] -f postgis.sql psql -d [yourdatabase] -f spatial_ref_sys.sql psql -d [yourdatabase] -f postgis_comments.sql 1 - http://postgis.refractions.net/documentation/manual-2.0/postgis_installation.html#create_new_db_extensions 2 - http://postgis.refractions.net/documentation/manual-1.5/ch02.html#id2661925 -- Marcone Peres - DBA http://www.linkedin.com/in/marconeperes @marconeperes (61) 8146-0028 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] problemas com: CREATE EXTENSION postgis;
pessoALL, boa tarde. Com relação a este post que impostei, verifiquei algumas coisas que podem ser indicativo de que nem tudo que fiz foi só besteira. Observei que no meu servidor PostgreSQL alem do banco que tenho nomeado de meu_banco há um banco chamado *postgres*. Este banco postgres, aparentemente contém tudo que penso que preciso, ou seja, nele há: a) schema public com *tables*: geometry_columns e spatial_ref_sys c) schema public com *views*: geography_columns d) schema public com *functions*: _st_asgeojson (integer, geometry, integer, integer) , ... , addpoint (geometry, geometry) , ... , zmin (box3d) (zilhoes de funções espaciais/geometricas etc) e) schema public com *types*: box2d, box3d, box3d_extent, chip, geography, geometry, geometry_dump, gidx, pgis_abs, spheroid f) etc, etc, etc Então, eu penso que se o banco postgres fosse definido como Template e este utilizado (no momento de) para criação do meu_banco, o banco meu_banco estaria apto a suportar a execução do CREATE EXTENSION, certo ? Porém o meu_banco já é um banco real e de produção e como eu poderia incrementar suporte PostGis nele ? Gratos: MN 2012/9/20 Marcos Aurelio Nobre marcono...@gmail.com sALLdações. Ambiente: Debian 6 / PostgreSQL 9.1 / PostGis 1.5 Estou recebendo a seguinte mensagem de erro ao tentar executar um CREATE EXTENSION : --* Erro de SQL:* ERROR: could not open extension control file /usr/share/postgresql/9.1/extension/postgis.control: No such file or directory* Indicação de entrada :* CREATE EXTENSION postgis; --- Observei o diretório /usr/share/postgresql/9.1/extension/ e realmente não há nada lá que se relacione com postgis. Para efeito de informação, para alguém que venha a me ajudar a encontrar a solução deste problema, encontrei alguns problemas na execução de um certo roteiro de instalação do POSTGIS. A seguir, vou descrever minimamente, algo que empreendi desse roteiro. 1 - instalação Tenho os seguintes pacotes instalados: ii postgresql 9.1+122ubuntu1 object-relational SQL database (supported version) ii postgresql-9.1 9.1.4-0ubuntu11.10 object-relational SQL database, version 9.1 server ii postgresql-9.1-debversion 1.0.6-1ubuntu1 Debian version number type for PostgreSQL ii postgresql-9.1-ip4r 1.05-0.1IPv4 and IPv4 range index types for PostgreSQL 9.1 ii postgresql-9.1-pljava-gcj 1.4.2-4ubuntu1 Java procedural language for PostgreSQL 9.1 ii postgresql-9.1-pllua 1:0.3.2-4 Lua procedural language for PostgreSQL 9.1 ii postgresql-9.1-plsh 1.3-5 PL/sh procedural language for PostgreSQL 9.1 ii postgresql-9.1-postgis 1.5.3-1ubuntu0.1Geographic objects support for PostgreSQL 9.1 ii postgresql-client 9.1+122ubuntu1 front-end programs for PostgreSQL (supported version) ii postgresql-client-9.1 9.1.4-0ubuntu11.10 front-end programs for PostgreSQL 9.1 ii postgresql-client-common 122ubuntu1 manager for multiple PostgreSQL client versions ii postgresql-common 122ubuntu1 PostgreSQL database-cluster manager ii postgresql-contrib 9.1+122ubuntu1 additional facilities for PostgreSQL (supported version) ii postgresql-contrib-9.1 9.1.4-0ubuntu11.10 additional facilities for PostgreSQL ii postgresql-doc 9.1+122ubuntu1 documentation for the PostgreSQL database management system ii postgresql-doc-9.1 9.1.4-0ubuntu11.10 documentation for the PostgreSQL database management system ii postgis 1.5.3-1ubuntu0.1Geographic objects support for PostgreSQL -- common files ii postgresql-9.1-postgis 1.5.3-1ubuntu0.1Geographic objects support for PostgreSQL 9.1 2 - configuração inicial 2.1 - no diretorio: /usr/share/postgresql/9.1/contrib e executei: psql -f postgis_comments.sql -d meu_banco - *ok* 2.2 - no diretorio: /usr/share/postgresql/9.1/contrib/postgis-1.5 executei: $ psql -f postgis.sql -d meu_banco - *que apresentou o seguinte resultado:* psql:postgis.sql:82: ERROR: type spheroid already exists psql:postgis.sql:92: ERROR: current transaction is aborted, commands ignored until end of transaction block psql:postgis.sql:98: ERROR: current transaction is aborted, commands ignored until end of transaction block psql:postgis.sql:104: ERROR: current transaction is aborted, commands ignored until end of transaction block psql:postgis.sql:110: ERROR: current transaction is aborted, commands ignored until end of transaction block ...
Re: [pgbr-geral] problemas com: CREATE EXTENSION postgis;
Em 20 de setembro de 2012 17:28, Marcos Aurelio Nobre marcono...@gmail.com escreveu: Então, eu penso que se o banco postgres fosse definido como Template e este utilizado (no momento de) para criação do meu_banco, o banco meu_banco estaria apto a suportar a execução do CREATE EXTENSION, certo ? Não. Como falei o postgis 1.5 não suporta CREATE EXTENSION. Porém o meu_banco já é um banco real e de produção e como eu poderia incrementar suporte PostGis nele ? Bastaria executar os scrips do postgis nele. Só uma dúvida... qual o resultado do comando abaixo: psql -d meu_banco -c 'select postgis_full_version()'; -- Marcone Peres - DBA http://www.linkedin.com/in/marconeperes @marconeperes (61) 8146-0028 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Sair da comunidade
Prezados, gostaria de sair da comunidade... Como devo proceder??? Obrigado! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] problemas com: CREATE EXTENSION postgis;
Marcone, agora estou com 2 dúvidas : 1) sua resposta implica em que eu deveria desinstalar os pacotes: postgis-1.5.3-1ubuntu0.1 e postgresql-9.1-postgis-1.5.3-1ubuntu0.1 e instalar os correlatos da versão 2.0 ? 2) será que eu encontro pacotes do postgis v2.0 para instalação via apt-get para o Ubuntu 11.10 , sem ter que compilar a partir dos fontes ? MN Em 20 de setembro de 2012 17:13, Marcone marconepe...@gmail.com escreveu: 2012/9/20 Marcos Aurelio Nobre marcono...@gmail.com: Estou recebendo a seguinte mensagem de erro ao tentar executar um CREATE EXTENSION : O Postgis só dá suporte ao comando CREATE EXTENSION à aprtir da versão 2.0 [1] (.) 2 - configuração inicial 2.1 - no diretorio: /usr/share/postgresql/9.1/contrib e executei: psql -f postgis_comments.sql -d meu_banco - ok 2.2 - no diretorio: /usr/share/postgresql/9.1/contrib/postgis-1.5 executei: $ psql -f postgis.sql -d meu_banco - que apresentou o seguinte resultado: psql:postgis.sql:82: ERROR: type spheroid already exists psql:postgis.sql:92: ERROR: current transaction is aborted, commands ignored until end of transaction block psql:postgis.sql:98: ERROR: current transaction is aborted, commands ignored until end of transaction block psql:postgis.sql:104: ERROR: current transaction is aborted, commands ignored until end of transaction block psql:postgis.sql:110: ERROR: current transaction is aborted, commands ignored until end of transaction block (...) A sequencia de execução dos scripts não foi obedecida. A ordem correta é [2]: psql -d [yourdatabase] -f postgis.sql psql -d [yourdatabase] -f spatial_ref_sys.sql psql -d [yourdatabase] -f postgis_comments.sql 1 - http://postgis.refractions.net/documentation/manual-2.0/postgis_installation.html#create_new_db_extensions 2 - http://postgis.refractions.net/documentation/manual-1.5/ch02.html#id2661925 -- Marcone Peres - DBA http://www.linkedin.com/in/marconeperes @marconeperes (61) 8146-0028 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sair da comunidade
Em 20/09/12, Marcus Túlio Ramosmarcustuliora...@gmail.com escreveu: Prezados, gostaria de sair da comunidade... Como devo proceder??? Obrigado! Vá em: https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral e siga as instruções descritas no final da página: Para se desinscrever de pgbr-geral, ... Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] problemas com: CREATE EXTENSION postgis;
O comando sugerido, deu como resposta: postgis_full_version --- POSTGIS=1.5.3 GEOS=3.2.2-CAPI-1.6.2 PROJ=Rel. 4.7.1, 23 September 2009 LIBXML=2.7.8 USE_STATS (procs from 1.5 r5385 need upgrade) (1 row) E agora ? MN Em 20 de setembro de 2012 17:33, Marcone marconepe...@gmail.com escreveu: Em 20 de setembro de 2012 17:28, Marcos Aurelio Nobre marcono...@gmail.com escreveu: Então, eu penso que se o banco postgres fosse definido como Template e este utilizado (no momento de) para criação do meu_banco, o banco meu_banco estaria apto a suportar a execução do CREATE EXTENSION, certo ? Não. Como falei o postgis 1.5 não suporta CREATE EXTENSION. Porém o meu_banco já é um banco real e de produção e como eu poderia incrementar suporte PostGis nele ? Bastaria executar os scrips do postgis nele. Só uma dúvida... qual o resultado do comando abaixo: psql -d meu_banco -c 'select postgis_full_version()'; -- Marcone Peres - DBA http://www.linkedin.com/in/marconeperes @marconeperes (61) 8146-0028 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] problemas com: CREATE EXTENSION postgis;
Em 20 de setembro de 2012 17:47, Marcos Aurelio Nobre marcono...@gmail.com escreveu: O comando sugerido, deu como resposta: postgis_full_version --- POSTGIS=1.5.3 GEOS=3.2.2-CAPI-1.6.2 PROJ=Rel. 4.7.1, 23 September 2009 LIBXML=2.7.8 USE_STATS (procs from 1.5 r5385 need upgrade) (1 row) E agora ? Isso quer dizer que o postgis 1.5.3 já está habilitado em sua base. :-) :-) :-) -- Marcone Peres - DBA http://www.linkedin.com/in/marconeperes @marconeperes (61) 8146-0028 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sair da comunidade
2012/9/20 Osvaldo Kussama osvaldo.kuss...@gmail.com: Vá em: https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral e siga as instruções descritas no final da página: Para se desinscrever de pgbr-geral, ... Como já relatei, o procedimento não funcionou para mim. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sair da comunidade
Como já relatei, o procedimento não funcionou para mim.
Moderador, favor alterar o comando:
delete from lista
where email = $1
and $1 'l...@dutras.org';
para
delete from lista
where email = $1
and $1 not in ('l...@dutras.org', outros possível emails);
k
Sem chane de você sair!!! :-)
--
Marcone Peres - DBA
http://www.linkedin.com/in/marconeperes
@marconeperes
(61) 8146-0028
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] problemas com: CREATE EXTENSION postgis;
Desculpe minha ignorancia (*) mas o pessoal do departamento de geoprocessamento precisa ou não do CREATE EXTENSION postgis ? Ou com a presença do Postgis eles já podem criar tabelas com a tal coluna sei-la-o-que-GDEON e se virarem com a coisa geo-referenciamento e etc ? (*) A ignorancia deve-se ao fato de que cuido somente da parte SGDB-*R* do banco. Em 20 de setembro de 2012 17:49, Marcone marconepe...@gmail.com escreveu: Em 20 de setembro de 2012 17:47, Marcos Aurelio Nobre marcono...@gmail.com escreveu: O comando sugerido, deu como resposta: postgis_full_version --- POSTGIS=1.5.3 GEOS=3.2.2-CAPI-1.6.2 PROJ=Rel. 4.7.1, 23 September 2009 LIBXML=2.7.8 USE_STATS (procs from 1.5 r5385 need upgrade) (1 row) E agora ? Isso quer dizer que o postgis 1.5.3 já está habilitado em sua base. :-) :-) :-) -- Marcone Peres - DBA http://www.linkedin.com/in/marconeperes @marconeperes (61) 8146-0028 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] problemas com: CREATE EXTENSION postgis;
Quando vc fala em sua base quer dizer: no tal banco postgres ? Se por acaso precisarem de tais habilidades também no meu_banco ainda haverá um certo dever-de-casa a fazer - correto ? MN Em 20 de setembro de 2012 17:49, Marcone marconepe...@gmail.com escreveu: Em 20 de setembro de 2012 17:47, Marcos Aurelio Nobre marcono...@gmail.com escreveu: O comando sugerido, deu como resposta: postgis_full_version --- POSTGIS=1.5.3 GEOS=3.2.2-CAPI-1.6.2 PROJ=Rel. 4.7.1, 23 September 2009 LIBXML=2.7.8 USE_STATS (procs from 1.5 r5385 need upgrade) (1 row) E agora ? Isso quer dizer que o postgis 1.5.3 já está habilitado em sua base. :-) :-) :-) -- Marcone Peres - DBA http://www.linkedin.com/in/marconeperes @marconeperes (61) 8146-0028 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sair da comunidade
2012/9/20 Marcone marconepe...@gmail.com: Sem chane de você sair!!! :-) Afe, e eu aguardando se alguém ainda se manifestará sobre o Google F1 para me ausentar novamente… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] problemas com: CREATE EXTENSION postgis;
2012/9/20 Marcos Aurelio Nobre marcono...@gmail.com: Desculpe minha ignorancia (*) mas o pessoal do departamento de geoprocessamento precisa ou não do CREATE EXTENSION postgis ? Não. Só, nessa versão, de executar os programetas indicados, se não me falha a memória, em /usr/share/doc/postgis ou coisa que o valha. Ou usar a versão 2, se possível. Ou com a presença do Postgis eles já podem criar tabelas com a tal coluna sei-la-o-que-GDEON e se virarem com a coisa geo-referenciamento e etc ? Podem. (*) A ignorancia deve-se ao fato de que cuido somente da parte SGDB-R do banco. O PostGIS é perfeitamente relacional. O que não é relacional é limitar‐se somente aos tipos definidos pelo sistema… o PostGIS basicamente estende os tipos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] problemas com: CREATE EXTENSION postgis;
Em 20 de setembro de 2012 18:00, Marcos Aurelio Nobre marcono...@gmail.com escreveu: Desculpe minha ignorancia (*) mas o pessoal do departamento de geoprocessamento precisa ou não do CREATE EXTENSION postgis ? Não por que com a versão do postgis que você está usando não há como usar o comando CREATE EXTENSION. Quando você for atualizar para o postgis 2.x, aí vc vai usar create extension. Ou com a presença do Postgis eles já podem criar tabelas com a tal coluna sei-la-o-que-GDEON e se virarem com a coisa geo-referenciamento e etc ? Sim. Só uma correção. As colunas georreferenciadas geralmente são nomeadas como the_geom. (*) A ignorancia deve-se ao fato de que cuido somente da parte SGDB-R do banco. Em 20 de setembro de 2012 18:02, Marcos Aurelio Nobre marcono...@gmail.com escreveu: Quando vc fala em sua base quer dizer: no tal banco postgres ? Se por acaso precisarem de tais habilidades também no meu_banco ainda haverá um certo dever-de-casa a fazer - correto ? Se você tiver dado o comando como eu te passei onde coloquei a base como meu banco, você não necessitará fazer mais nada. -- Marcone Peres - DBA http://www.linkedin.com/in/marconeperes @marconeperes (61) 8146-0028 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] spclocation
Ah, certo. Bruno E. A. Silva. 2012/9/20 Matheus de Oliveira matioli.math...@gmail.com: 2012/9/20 Bruno Silva bemanuel...@gmail.com Eu uso muito o apgdiff e me atende bem. Você já o usou? Eu pessoalmente só fiz testes com ele, mas tem um pessoal aqui na empresa usando e está atendendo bem. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados PostgreSQL Dextra Sistemas - MPS.Br nível F! www.dextra.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] copiar tabelas fisicamente
Alguém sabe se é possível e como copiar tabelas fisicamente entre diferentes clusters? Tenho várias tabelas particionadas e preciso mover periodicamente partições de uma base de produção para uma base histórica. Sei que posso mover dados com um simples dump, mas isso custa muito, mito caro. Queria saber se é possível, mexer com segurança debaixo do capô dos datafiles e fazer este tipo de movimentação. -- Atenciosamente, Fábio Telles Rodriguez blog: http:// http://www.midstorm.org/~telles/http://tellesr.wordpress.com e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] copiar tabelas fisicamente
Em 20-09-2012 20:10, Fábio Telles Rodriguez escreveu: Alguém sabe se é possível e como copiar tabelas fisicamente entre diferentes clusters? Tenho várias tabelas particionadas e preciso mover periodicamente partições de uma base de produção para uma base histórica. Sei que posso mover dados com um simples dump, mas isso custa muito, mito caro. Queria saber se é possível, mexer com segurança debaixo do capô dos datafiles e fazer este tipo de movimentação. Certamente que não. Motivos: 1) As tabelas são nomeadas com o relfilenode que é guardado em catálogo de sistema. Não sei como você criaria esses dados em catálogo sem correr riscos. 2) Algumas informações do mapa de visibilidade sobre as transações já concluídas são guardadas em mapa de bits no diretório pg_clog que é para todo o cluster 3) As informações de transações correntes são guardadas em mapa de bits nos diretórios pg_multixact, pg_subtrans e pg_twophase, que também são para todo o cluster. Acho que você terá graves problemas se tentar algo desse tipo, linhas que já passaram por limpeza ou congelamento podem se tornar visíveis novamente, por exemplo, vide bug no pg_upgrade corrigido na versão 9.0.4 que justamente confundia isso, e eu já perdi dados por isso. Obóviamente Mr. Taveira pode ser mais claro que eu :) Não sei se tem algo no todo relativo a tablespaces portáteis para o PostgreSQL, mas numa conversa com o Bruce Momjian uma vez ele me explicou que muitas informações das tabelas são cluster wide e, portanto, um retrabalho muito grande de código paralizaria outros desenvolvimentos mais importantes. Pergunto: por que é tão caro assim fazer os dumps que você está citando? A restauração até entendo, mas o dump não deveria ser uma dor tão insuportável. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sair da comunidade
Então coloca na sua lista de spam :) Ou excluir direto no sevidor -Mensagem Original- From: Guimarães Faria Corcete DUTRA, Leandro Sent: Thursday, September 20, 2012 5:49 PM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] Sair da comunidade 2012/9/20 Osvaldo Kussama osvaldo.kuss...@gmail.com: Vá em: https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral e siga as instruções descritas no final da página: Para se desinscrever de pgbr-geral, ... Como já relatei, o procedimento não funcionou para mim. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] copiar tabelas fisicamente
On 20-09-2012 20:31, Flavio Henrique Araque Gurgel wrote: Em 20-09-2012 20:10, Fábio Telles Rodriguez escreveu: Alguém sabe se é possível e como copiar tabelas fisicamente entre diferentes clusters? Se fosse fácil assim não teria muita graça. ;) Tenho várias tabelas particionadas e preciso mover periodicamente partições de uma base de produção para uma base histórica. Sei que posso mover dados com um simples dump, mas isso custa muito, mito caro. Queria saber se é possível, mexer com segurança debaixo do capô dos datafiles e fazer este tipo de movimentação. Por que a cópia de segurança lógica é tão cara? Perda de performance? Você não dispõe de um standby para fazer essa cópia de segurança a partir dele? Já pensou em utilizar alguma das ferramentas de replicação lógica (Slony, Londiste ou Bucardo) ? Certamente que não. Motivos: 1) As tabelas são nomeadas com o relfilenode que é guardado em catálogo de sistema. Não sei como você criaria esses dados em catálogo sem correr riscos. 2) Algumas informações do mapa de visibilidade sobre as transações já concluídas são guardadas em mapa de bits no diretório pg_clog que é para todo o cluster Acho que você misturou as coisas... Mapa de visibilidade é um artifício para acelerar o VACUUM; se ele se perder, pode ser reconstruído _automagicamente_ (pelo VACUUM). 3) As informações de transações correntes são guardadas em mapa de bits nos diretórios pg_multixact, pg_subtrans e pg_twophase, que também são para todo o cluster. 4) Se a arquitetura for diferente, você não conseguirá manipular os datafiles. Não sei se tem algo no todo relativo a tablespaces portáteis para o PostgreSQL, mas numa conversa com o Bruce Momjian uma vez ele me explicou que muitas informações das tabelas são cluster wide e, portanto, um retrabalho muito grande de código paralizaria outros desenvolvimentos mais importantes. Não existe o conceito de tablespace portável ou mesmo tabela portável ainda. Concordo que seria um esforço enorme para um caso de uso pequeno senão ínfimo. A replicação lógica cobre essa lacuna. FYI está em desenvolvimento a replicação lógica no core; possivelmente na 9.3 teremos esse recurso sem precisar utilizar alguma ferramenta externa. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] copiar tabelas fisicamente
Em 20 de setembro de 2012 20:31, Flavio Henrique Araque Gurgel fla...@4linux.com.br escreveu: Certamente que não. Motivos: 1) As tabelas são nomeadas com o relfilenode que é guardado em catálogo de sistema. Não sei como você criaria esses dados em catálogo sem correr riscos. 2) Algumas informações do mapa de visibilidade sobre as transações já concluídas são guardadas em mapa de bits no diretório pg_clog que é para todo o cluster 3) As informações de transações correntes são guardadas em mapa de bits nos diretórios pg_multixact, pg_subtrans e pg_twophase, que também são para todo o cluster. Concordo... Acho que você terá graves problemas se tentar algo desse tipo, linhas que já passaram por limpeza ou congelamento podem se tornar visíveis novamente, por exemplo, vide bug no pg_upgrade corrigido na versão 9.0.4 que justamente confundia isso, e eu já perdi dados por isso. Será que revogando todos acessos a relação e após um checkpoint não é possível fazer essa operação? Até pq o pg_upgrade faz +- o que o Telles precisa, ou estou errado? Fiz uns testes aqui e claro que funcionou até porque é um ambiente controlado e não existe alta concorrencia de acesso aos objetos, mas fiz assim: 1) Revoguei todas permissões de acesso a tabela 2) Checkpoint 3) pg_dump -s da tabela e restaurei esse dump no outro banco 4) Verifiquei os arquivos fisicos a serem copiados pelo catalogo na origem (guardei o pg_class.relfilenode) 5) Verifiquei os arquivos fisicos a serem copiados pelo catalogo no destino (guardei o pg_class.relfilenode) 6) Copiei os arquivos (pg_class.relfilenode) com o relfilenode na origem para o relfilenode do destino (substituindo assim o datafile) 7) Recuperei as permissões de acesso a tabela no destino e os dados estavam lá Obs: Eu copiei TUDO (tabelas, sequencias e indices) Obóviamente Mr. Taveira pode ser mais claro que eu :) É verdade... colabora ai Euler... Não sei se tem algo no todo relativo a tablespaces portáteis para o PostgreSQL, mas numa conversa com o Bruce Momjian uma vez ele me explicou que muitas informações das tabelas são cluster wide e, portanto, um retrabalho muito grande de código paralizaria outros desenvolvimentos mais importantes. Imagino mesmo que não seja algo trivial Pergunto: por que é tão caro assim fazer os dumps que você está citando? A restauração até entendo, mas o dump não deveria ser uma dor tão insuportável. Mas eu acho que o principal problema do Telles ai pode ser a restauração mesmo... Att, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Google F1, ‘o retorno’
Em 20 de setembro de 2012 10:45, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/9/18 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org: Interessantemente, parece que o F1 é construído sobre o Spanner http://research.google.com/archive/spanner.html, que parece ser mais relacional que o SQL, requerendo que toda tabela tenha uma chave — ou seja, trabalha com relações de fato. Alguém chegou a analisar o aspecto relacional do Spanner? Não li os blue-papers do Spanner, e também não sei se entendi corretamente o F1 (li a apresentação na íntegra agora, cansado...), mas eu diria que ficaram alguns pontos de interrogação que achei interessante discutir: - Se pretende realmente implementar o puro aspecto relacional, como é a API para fazer as consultas à base de dados'? Isso não seria um /*caveat/* por obrigar aos programadores a aprender toda a teoria relacional, já que muitos mal compreendem a SQL? (eu por exemplo, trabalho com SQL a quase 10 anos e até hoje ainda não entendo completamente o conceito da álgebra relacional); - Ao que vi, a SQL nada mais é que uma extensão, o acesso aos dados será feito inicialmente por uma API. Como seriam tratadas as falhas da SQL - que você mesmo menciona várias vezes na lista. Talvez houvesse a preferência seria por utilizar a extensão SQL ao invés da API, dada a grande portabilidade existente hoje - e facilidade de compreensão em relação às expressões em A.R. - Há uma perda de desempenho na gravação para obter desempenho na leitura. Eu diria que com uma view materializada haveria o mesmo comportamento. Mas ainda assim o desempenho é menor que o MySQL. Parece que não houve vantagem até o momento no ponto de vista desempenho - talvez se usassem PostgreSQL... :) - Índices consistentes (Consistent Indexes). O que significa? Algo como não é necessário reconstruí-los? - Leituras em paralelo: excelente. Sem mais comentários a respeito disso. - Buffer writes in client, send as one RPC: E quando houver concorrência com várias conexões, como fica a capacidade do servidor de responder a tantas requisições, digamos, grandes? - Permite o não-uso de ORM com um OM. Maravilha! Menos frameworks para se configurar, menos componentes intermediando a conversa APP-SGBD. Mas e a API (Library), como é? Vai usar a linguagem da A.R? Ou a notação de objetos a exemplo do Java? Fiquei curioso... Por fim... se eu falei besteira e não entendi, me desculpe e corrige aí, ou pelo menos dá seu ponto de vista. Apesar de algumas funcionalidades apresentadas parecem ter algum sentido/vantagem, eu ainda diria que é cedo para pensar no F1 como a solução dos problemas ORM (e todas suas variações) X SGBD Relacional X Álgebra Relacional. Talvez sua complexidade não seja atraente. -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
