[pgbr-geral] Replicação de base de produção diária
Pessoal, Nós aqui na empresa temos a necessidade de restaurar uma base diariamente com os dados de produção para que sejam desenvolvidas algumas correções de dados e fazer testes para depois serem aplicados em produção. Ou seja, todo dia por volta das 22:00 é feito um dump de produção, e assim que o processo é finalizado é iniciado um restore da base em um outro servidor. O ambiente muitas vezes é modificado estruturalmente e os dados dele durante o dia, porém no dia seguinte precisa iniciar com a estrutura e dados do ambiente de produção. Por isso a necessidade de restaurá-lo do zero diariamente com os dados de produção. Alguém tem uma situação semelhante ou alguma idéia de um processo melhor? Pois atualmente esse processo está levando por volta de 9 horas.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação de base de produção diária
> Pessoal, > > Nós aqui na empresa temos a necessidade de restaurar uma base diariamente > com os dados de produção para que sejam desenvolvidas algumas correções de > dados e fazer testes para depois serem aplicados em produção. > > Ou seja, todo dia por volta das 22:00 é feito um dump de produção, e assim > que o processo é finalizado é iniciado um restore da base em um outro > servidor. > > O ambiente muitas vezes é modificado estruturalmente e os dados dele > durante o dia, porém no dia seguinte precisa iniciar com a estrutura e > dados do ambiente de produção. Por isso a necessidade de restaurá-lo do > zero diariamente com os dados de produção. > > Alguém tem uma situação semelhante ou alguma idéia de um processo melhor? > Pois atualmente esse processo está levando por volta de 9 horas. > > Você esta usando a opção -j tanto do pg_dump e do pg_restore? Se você já tiver usando a saída é utilizar PIRT, o barman[1] pode te ajudar bastante com isso. [1] http://www.pgbarman.org/ - Glauco Torres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] PGBR2015 - Palestras
Pessoal, Primeiramente quero parabenizar a organização do PGBR2015 que foi muito boa, com palestras e tutoriais enriquecedores. Gostaria de saber quando teremos acesso ao material das palestras. []'s -- Rogério Cunha Carvalho "Muitos são os planos no coração do homem, mas o que prevalece é o propósito do Senhor." Provérbios 19:21 "There are many plans in a man's heart; nevertheless the counsel of the LORD, that shall stand." Proverbs 19:21 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Replicação de base de produção diária
Glauco, Obrigado pelo retorno. Sim, já utilizamos a opção -j. Eu vi em uma palestra no PGBR a respeito do barman, vou dar uma olhada. Em 23 de nov de 2015 às 09:44, Glauco Torres escreveu: Pessoal, Nós aqui na empresa temos a necessidade de restaurar uma base diariamente com os dados de produção para que sejam desenvolvidas algumas correções de dados e fazer testes para depois serem aplicados em produção. Ou seja, todo dia por volta das 22:00 é feito um dump de produção, e assim que o processo é finalizado é iniciado um restore da base em um outro servidor. O ambiente muitas vezes é modificado estruturalmente e os dados dele durante o dia, porém no dia seguinte precisa iniciar com a estrutura e dados do ambiente de produção. Por isso a necessidade de restaurá-lo do zero diariamente com os dados de produção. Alguém tem uma situação semelhante ou alguma idéia de um processo melhor? Pois atualmente esse processo está levando por volta de 9 horas. Você esta usando a opção -j tanto do pg_dump e do pg_restore? Se você já tiver usando a saída é utilizar PIRT, o barman[1] pode te ajudar bastante com isso. [1] http://www.pgbarman.org/ - Glauco Torres ___ 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] Replicação de base de produção diária
On 23-11-2015 08:32, Gilberto Gonçalves Machado wrote: > Nós aqui na empresa temos a necessidade de restaurar uma base > diariamente com os dados de produção para que sejam desenvolvidas > algumas correções de dados e fazer testes para depois serem aplicados em > produção. > > Ou seja, todo dia por volta das 22:00 é feito um dump de produção, e > assim que o processo é finalizado é iniciado um restore da base em um > outro servidor. > Você não informou a versão. A partir da 8.4 você consegue fazer a restauração em paralelo e a partir da 9.3 você consegue fazer a cópia (aka dump) em paralelo. > Alguém tem uma situação semelhante ou alguma idéia de um processo > melhor? Pois atualmente esse processo está levando por volta de 9 horas. > Você não apresentou números (tamanho, número de tabelas, ...). E nem relatou se há várias bases no _cluster_ e se todas elas vão ser replicadas. Caso tenha que enviar (quase) todos os dados e o gargalo for justamente o processo de cópia/restauração lógica, eu sugiro que você mude para cópia/restauração física. Se os dados do dia anterior estiverem sendo descartados, sugiro utilizar o rsync para acelerar o processo de cópia. -- Euler Taveira 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] PGBR2015 - Palestras
On Mon, Nov 23, 2015 at 10:02:02AM -0200, Rogerio Carvalho wrote: > Gostaria de saber quando teremos acesso ao material das palestras. Estamos contatando os palestrantes e solicitando que enviem as palestras para nos, tão logo estejam disponivel publicaremos no site e aqui. []s Guedes signature.asc Description: Digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tipos de dados
> > Antes de chegarmos no nivel de escovar bits, recomendo que faça alguns > testes com o teu volume de dados e avalie qual deles tem um melhor > desempenho. Creio eu que comparação de números tende a ser mais eficiente > que strings. Teste e voltamos a conversar, ok? > > > Como vocês disseram nas palestras...contribuam...eu sou amador aqui perto de vocês, mas gostaria de deixar minha consideração. Aqui utilizamos para CPF e CNPJ varchar(14), mas isso é herança de 1997 e não tenho ideia do trabalho que daria para alterar, mas fiz uns testes baseados numa apresentação que li uma vez do Juliano Atanazio, e aqui está o resultado: select 'bigint', pg_size_pretty( sum(pg_column_size( 99::bigint )) ) union select 'char_14', pg_size_pretty( sum(pg_column_size( '99'::char(14) )) ) union select 'char_20', pg_size_pretty( sum(pg_column_size( '99'::char(20) )) ); char_14 : 18 bytes char_20 : 24 bytes bigint : 8 bytes Achei interessante, e vai de encontro a resposta do Sebastian quanto a usar numéricos. Att, Fernando Luís Cambiaghi. (Analista de Sistemas Sênior) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tipos de dados
Em 23 de novembro de 2015 14:05, Fernando Cambiaghi escreveu: > Antes de chegarmos no nivel de escovar bits, recomendo que faça alguns >> testes com o teu volume de dados e avalie qual deles tem um melhor >> desempenho. Creio eu que comparação de números tende a ser mais eficiente >> que strings. Teste e voltamos a conversar, ok? >> >> >> Como vocês disseram nas palestras...contribuam...eu sou amador aqui perto > de vocês, mas gostaria de deixar minha consideração. > Não veja isso de forma negativa. Todos aqui podemos aprender auxiliando uns aos outros. Não importa quão experiente seja. Chegou a dar uma olhada nas URLs que te mandei? Vi que no modulo de validações feito pelo guedes ele já implementa o tipo de dados cpf. e com isso já facilita a validação do mesmo como numeric. > Aqui utilizamos para CPF e CNPJ varchar(14), mas isso é herança de 1997 e > não tenho ideia do trabalho que daria para alterar, mas fiz uns testes > baseados numa apresentação que li uma vez do Juliano Atanazio, e aqui está > o resultado: > > select 'bigint', pg_size_pretty( sum(pg_column_size( > 99::bigint )) ) > union > select 'char_14', pg_size_pretty( sum(pg_column_size( > '99'::char(14) )) ) > union > select 'char_20', pg_size_pretty( sum(pg_column_size( > '99'::char(20) )) ); > > char_14 : 18 bytes > char_20 : 24 bytes > bigint : 8 bytes > :D > > Achei interessante, e vai de encontro a resposta do Sebastian quanto a > usar numéricos. > Faça o teste da comparação e veja qual é mais eficiente. Com fatos, fica fácil tomar a escolha correta. Ou pelo menos ter uma idéia de qual seria a solução ideal. -- Sebastian Webber http://swebber.me ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] PGBR 2015
Olá, Gostaria de agradecer à todo que fizeram acontecer a Conferência PostgreSQL Brasil 2015, dos participantes, palestrantes e organização. Especialmente à organização por realizar o evento. :) Espero que ano que vem ocorra o evento novamente, afinal serão 10 anos! A, minha apresentação está no Slideshare[1]. [1] - http://www.slideshare.net/fernandoike/a-postgersql-brasil-lista-caiu P.S.: Desculpem o cross-posting. ;) []'s -- Fernando Ike ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tipos de dados
On Mon, Nov 23, 2015 at 02:05:22PM -0200, Fernando Cambiaghi wrote: > > Antes de chegarmos no nivel de escovar bits, recomendo que faça alguns > > testes com o teu volume de dados e avalie qual deles tem um melhor > > desempenho. Creio eu que comparação de números tende a ser mais eficiente > > que strings. Teste e voltamos a conversar, ok? > > > > > > Como vocês disseram nas palestras...contribuam...eu sou amador aqui perto > de vocês, mas gostaria de deixar minha consideração. > Aqui utilizamos para CPF e CNPJ varchar(14), mas isso é herança de 1997 e > não tenho ideia do trabalho que daria para alterar, mas fiz uns testes > baseados numa apresentação que li uma vez do Juliano Atanazio, e aqui está > o resultado: > > select 'bigint', pg_size_pretty( sum(pg_column_size( 99::bigint > )) ) > union > select 'char_14', pg_size_pretty( sum(pg_column_size( > '99'::char(14) )) ) > union > select 'char_20', pg_size_pretty( sum(pg_column_size( > '99'::char(20) )) ); > > char_14 : 18 bytes > char_20 : 24 bytes > bigint : 8 bytes > > Achei interessante, e vai de encontro a resposta do Sebastian quanto a usar > numéricos. Ola Fernando, Eu li a sua premissa e a sua conclusão e não entendi, mas acho que voce quis dizer que vai _ao_ encontro da resposta do Sebastian, já que, pelo que eu entendi, vocẽ esta concordando com ele. Seria isso? Outra coisa, voce chegou a testar com numeric(14) e ver o impacto? Voce pode testar com numeros aleatorios tambem para avaliar. Se o fizer poste o resultado para conhecimento de todos. Em tempo, todos somos amadores e ignorantes em muitas coisas e mesmo assim sempre poderemos contribuir com algo, por mais simples que seja. []s Guedes signature.asc Description: Digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tipos de dados
2015-11-23 14:26 GMT-02:00 Sebastian Webber : > > Chegou a dar uma olhada nas URLs que te mandei? Vi que no modulo de > validações feito pelo guedes ele já implementa o tipo de dados cpf. e com > isso já facilita a validação do mesmo como numeric. Sendo um pouco chato, mas no interesse da precisão, até onde entendi o módulo — muito útil — implementa um DOMAIN SQL, o que não é um domínio (!), portanto não é um tipo de dado; mas é a coisa mais parecida, e útil, com um domínio de verdade. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tipos de dados
2015-11-22 22:47 GMT-02:00 Gerdan Rezende dos Santos : > Cpf com zero?? O meu comeca assim 001... Te respondi??? Não. Perguntei ‘que têm’, quer dizer, que diferença faz (dado tudo que já conversamos até aqui). > Transformação no banco custa, banco e pra armazanar e consultar Armazenamento e consulta também custam. A avaliar o que custa mais. E outra: geralmente o gargalo num sistema é E/S, não processamento. Portanto, geralmente vale a pena economizar armazenamento se o custo em processamento não for exagerado. E não parece ser. > quer deixar bonito bota na aplicacao A aplicação pode estar na base de dados também. Aliás, é o melhor lugar para ficar, garantindo consistência em qualquer uso, por qualquer programa aplicativo, e compartilhando recursos com o resto do servidor. > se a mascara for executada no cliente melhor ainda... Pior. Quanto mais perto dos dados, melhor, tanto em velocidade (latência, compartilhamento de recursos) quanto em consistência. > Pq usar char?? Poderia comecar te dizendo pra ser ter um padrão no seu > armazanamento... Um padrão qualquer é melhor que padrão nenhum. Mas um padrão específico não é obviamente mais útil em si mesmo que um padrão alternativo, sem alguma explicação. > Ah qto a você me sacanear... Não sacaneei nada. Só achei que você seria capaz de contribuir ainda mais. > Sua preoculpação deveria ser em ajudar ao colega E foi. > eu não sou dono da verdade! Mas escreveu como se achasse ser. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PGBR 2015
Em 23 de novembro de 2015 14:22, Fernando Ike escreveu: > Olá, > > Gostaria de agradecer à todo que fizeram acontecer a Conferência > PostgreSQL Brasil 2015, dos participantes, palestrantes e organização. > Especialmente à organização por realizar o evento. :) > :D > > Espero que ano que vem ocorra o evento novamente, afinal serão 10 > anos! > Quando será que podemos falar em pgbr2016? eu to interessado em ajudar. :D -- Sebastian Webber http://swebber.me ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tipos de dados
Em 23 de novembro de 2015 15:13, Guimarães Faria Corcete DUTRA, Leandro < l...@dutras.org> escreveu: > 2015-11-23 14:26 GMT-02:00 Sebastian Webber : > > > > Chegou a dar uma olhada nas URLs que te mandei? Vi que no modulo de > > validações feito pelo guedes ele já implementa o tipo de dados cpf. e com > > isso já facilita a validação do mesmo como numeric. > > Sendo um pouco chato, mas no interesse da precisão, até onde entendi o > módulo — muito útil — implementa um DOMAIN SQL, o que não é um domínio > (!), portanto não é um tipo de dado; mas é a coisa mais parecida, e > útil, com um domínio de verdade. Meu caro Dutra, segundo a doc[1], dá pra dizer que: CREATE DOMAIN creates a new domain. A domain is essentially a data type with optional constraints (restrictions on the allowed set of values) ... ... Domains are useful for abstracting common constraints on fields into a single location for maintenance. For example, several tables might contain email address columns, all requiring the same CHECK constraint to verify the address syntax. Define a domain rather than setting up each table's constraint individually. Chamamos isso de empate técnico? :D [1] http://www.postgresql.org/docs/current/static/sql-createdomain.html -- Sebastian Webber http://swebber.me ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tipos de dados
2015-11-23 15:58 GMT-02:00 Sebastian Webber : > > Meu caro Dutra, segundo a doc[1], dá pra dizer que: > > CREATE DOMAIN creates a new domain. A domain is essentially a data type with > optional constraints (restrictions on the allowed set of values) ... Então, mais ou menos… esse é um ponto em que nossa documentação comete um erro conceitual grosseiro. > Domains are useful for abstracting common constraints on fields into a > single location for maintenance. Perfeito, mas não apenas. O DOMAIN do SQL, que o PostgreSQL segue, não é domínio de verdade. Creio que já (tentei) explicar isso aqui antes, mas como é um dos meus assuntos favoritos, tentarei de novo: Um domínio é uma lista de valores — conceitualmente, porque podem ser valores contínuos (não discretos), caso em que a lista não pode ser realizada; idem para domínios infinitos. Um tipo de dados é um domínio e seus operadores. Por exemplo, no caso ‘em tela’ (jargão aqui de Brasília), um CPF é um número de até onze caracteres, ou precisamente onze se o precedermos de zeros. Até onde eu saiba; perdoem alguma imprecisão no exemplo. O domínio CPF é constituído de todos os números de CPF válidos. Como apenas os nove números excluindo os dois dígitos verificadores à direita são relevantes para gerar a lista, podemos dizer que o domínio, a princípio, seria de 1 a 999.999.999, concatenados com os respectivos dígitos verificadores. No caso, suponho que 0 seja um caso especial, ou seja, que não haja um CPF 0-XX onde XX seriam os DVs correspondentes a 0. Já o tipo de dados seriam os operadores correspondentes. Não consigo imaginar, de bate-pronto, algum operador que não seja o de identidade (comparação para ver se é igual ou diferente); por exemplo, não me parece fazer sentido querer concatenar, cortar, somar, subtrair, multiplicar, dividir, comparar se maior ou menos &c. Talvez operadores para extrair os dígitos significativos (os nove excetuando os DVs) e os dígitos verificadores. O interessante a reter é que não faz sentido operar num determinado domínio com operadores que não correspondam ao tipo. Portanto, por definição, uma definição de domínio tem de excluir operações de outros tipos (por exemplo, concatenar ou multiplicar CPFs), ou que envolvam outros domínios sem que sejam operações especificamente previstas para o domínio em questão e outro domínio qualuqer (por exemplo, concatenar um CPF com um CNPJ, ou multiplicar um CPF por um CNPJ). Até onde já li e testei, um DOMAIN SQL não impede isso. Teste; deve ser possível CREATE TABLE cpf (cpf AS cpf); com esse DOMAIN, e fazer um SELECT cpf * 2 FROM cpf;, o que não seria possível com um domínio de verdade. Aproveitando para bater noutra tecla que me é cara, é por causa desse tipo de problema de confusão conceitual (embora não desse problema específico) que o SQL não é relacional: para começo de conversa, uma tabela SQL não necessariamente é uma relação (que precisa de ao menos uma chave natural), mas pode ser um saco (sem chave natural, ou seja, não é um conjunto). > For example, several tables might contain > email address columns, all requiring the same CHECK constraint to verify the > address syntax. Define a domain rather than setting up each table's > constraint individually. Ou seja, é útil mesmo sem ser um domínio: é um atalho para declarar uma restrição de validação. > Chamamos isso de empate técnico? :D > > [1] http://www.postgresql.org/docs/current/static/sql-createdomain.htm Posso dizer que não é uma disputa, portanto não faz sentido falar em empate? ;-) -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] REF: Lendo tipo Bytea
Olá Pessoal, Tenho um campo tipo bytea, nele gravo um conteúdo XML. Quando leio este conteúdo localmente retorna OK, porem em produção no servido web ele retorna em Hexa. Alguém pode dar uma dica ? Att, Paulo. VisualP Sistemas ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] REF: Lendo tipo Bytea
Em 23 de novembro de 2015 16:34, Paulo escreveu: > Olá Pessoal, > > > > Tenho um campo tipo bytea, nele gravo um conteúdo XML. > > Quando leio este conteúdo localmente retorna OK, porem em produção no > servido web ele retorna em Hexa. > > > > Alguém pode dar uma dica ? > Verifique o parâmetro bytea_output de ambos os servidores. Creio que sejam servidores/clusters distintos, correto? O comando pode ser executado via psql mesmo: show bytea_output; Provavelmente um deles deve ser escape e o outro hexa. Vale checar também as versões, pois não tenho certeza de qual delas implementa o output em hexadecimal como default. []'s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] REF: Lendo tipo Bytea
On Mon, Nov 23, 2015 at 04:34:18PM -0200, Paulo wrote: > Olá Pessoal, > > Tenho um campo tipo bytea, nele gravo um conteúdo XML. > > Quando leio este conteúdo localmente retorna OK, porem em produção no > servido web ele retorna em Hexa. > > Alguém pode dar uma dica ? Indico a leitura da sessão apropriada [1] do manual do Postgres em que, além de explicar alguns funcionamentos, voce verá tambem que a saida gerada por um campo bytea pode ser diferente em função de uma configuração especifica. Você não comentou a versão do banco, sendo assim caso não seja a ultima (9.4) troque "current" no link [1] pela versão correspondente. [1] http://www.postgresql.org/docs/current/static/datatype-binary.html []s Guedes signature.asc Description: Digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tipos de dados
Em 23/11/15, Guimarães Faria Corcete DUTRA, Leandro escreveu: > 2015-11-23 15:58 GMT-02:00 Sebastian Webber : >> >> Meu caro Dutra, segundo a doc[1], dá pra dizer que: >> >> CREATE DOMAIN creates a new domain. A domain is essentially a data type >> with >> optional constraints (restrictions on the allowed set of values) ... > > Então, mais ou menos… esse é um ponto em que nossa documentação comete > um erro conceitual grosseiro. > > >> Domains are useful for abstracting common constraints on fields into a >> single location for maintenance. > > Perfeito, mas não apenas. > > O DOMAIN do SQL, que o PostgreSQL segue, não é domínio de verdade. > Creio que já (tentei) explicar isso aqui antes, mas como é um dos meus > assuntos favoritos, tentarei de novo: > > Um domínio é uma lista de valores — conceitualmente, porque podem ser > valores contínuos (não discretos), caso em que a lista não pode ser > realizada; idem para domínios infinitos. Um tipo de dados é um > domínio e seus operadores. > > Por exemplo, no caso ‘em tela’ (jargão aqui de Brasília), um CPF é um > número de até onze caracteres, ou precisamente onze se o precedermos > de zeros. Até onde eu saiba; perdoem alguma imprecisão no exemplo. O > domínio CPF é constituído de todos os números de CPF válidos. Como > apenas os nove números excluindo os dois dígitos verificadores à > direita são relevantes para gerar a lista, podemos dizer que o > domínio, a princípio, seria de 1 a 999.999.999, concatenados com os > respectivos dígitos verificadores. No caso, suponho que 0 seja um > caso especial, ou seja, que não haja um CPF 0-XX onde XX seriam os DVs > correspondentes a 0. > > Já o tipo de dados seriam os operadores correspondentes. Não consigo > imaginar, de bate-pronto, algum operador que não seja o de identidade > (comparação para ver se é igual ou diferente); por exemplo, não me > parece fazer sentido querer concatenar, cortar, somar, subtrair, > multiplicar, dividir, comparar se maior ou menos &c. Talvez > operadores para extrair os dígitos significativos (os nove excetuando > os DVs) e os dígitos verificadores. > > O interessante a reter é que não faz sentido operar num determinado > domínio com operadores que não correspondam ao tipo. Portanto, por > definição, uma definição de domínio tem de excluir operações de outros > tipos (por exemplo, concatenar ou multiplicar CPFs), ou que envolvam > outros domínios sem que sejam operações especificamente previstas para > o domínio em questão e outro domínio qualuqer (por exemplo, concatenar > um CPF com um CNPJ, ou multiplicar um CPF por um CNPJ). > > Até onde já li e testei, um DOMAIN SQL não impede isso. Teste; deve > ser possível CREATE TABLE cpf (cpf AS cpf); com esse DOMAIN, e fazer > um SELECT cpf * 2 FROM cpf;, o que não seria possível com um domínio > de verdade. > > Aproveitando para bater noutra tecla que me é cara, é por causa desse > tipo de problema de confusão conceitual (embora não desse problema > específico) que o SQL não é relacional: para começo de conversa, uma > tabela SQL não necessariamente é uma relação (que precisa de ao menos > uma chave natural), mas pode ser um saco (sem chave natural, ou seja, > não é um conjunto). > > >> For example, several tables might contain >> email address columns, all requiring the same CHECK constraint to verify >> the >> address syntax. Define a domain rather than setting up each table's >> constraint individually. > > Ou seja, é útil mesmo sem ser um domínio: é um atalho para declarar > uma restrição de validação. > > >> Chamamos isso de empate técnico? :D >> >> [1] http://www.postgresql.org/docs/current/static/sql-createdomain.htm > > Posso dizer que não é uma disputa, portanto não faz sentido falar em > empate? ;-) > > Olá Dutra: Não sei se existe CPF 0-XX mas o CNPJ do Banco de Brasil é: 00.000.000/0001-91 Que, pelas suas considerações, seria um domínio de 0 a acrescido da filial, de 0001 a , e dos DV. 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] Tipos de dados
2015-11-23 17:24 GMT-02:00 Osvaldo Kussama : > Não sei se existe CPF 0-XX mas o CNPJ do Banco de Brasil é: > 00.000.000/0001-91 Boa! ;-) > Que, pelas suas considerações, seria um domínio de 0 a > acrescido da filial, de 0001 a , e dos DV. Exato. Mais uma vez, imagino que não haja CNPJ 00.000.000/, ou filiais /. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tipos de dados
Em 21 de novembro de 2015 18:14, Flavio Henrique Araque Gurgel escreveu: > > http://pgxn.org/dist/validadores/ Esta extensão é antiga, criei ela no PGBR 2011 como demonstração e no PGDay PR publiquei a mesma na PGXN em caráter de demonstração também. Mas estamos em 2015 então criei vergonha na cara e coloquei o projeto no Github [1] para quem quiser contribuir. :D [1] https://github.com/guedes/validadores Obrigado! -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://github.com/guedes - http://guedesoft.net http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tipos de dados
Em 23 de novembro de 2015 19:32, Dickson S. Guedes escreveu: > Em 21 de novembro de 2015 18:14, Flavio Henrique Araque Gurgel > escreveu: > > > > http://pgxn.org/dist/validadores/ > > Esta extensão é antiga, criei ela no PGBR 2011 como demonstração e no > PGDay PR publiquei a mesma na PGXN em caráter de demonstração também. > Mas estamos em 2015 então criei vergonha na cara e coloquei o projeto > no Github [1] para quem quiser contribuir. :D > > [1] https://github.com/guedes/validadores Quem sabe a gente não faz um esforço e já implementamos os caras que faltam? E quero dizer CNPJ, titulo eleitor, telefone, etc e etc. Eu já comecei a implementar o CNPJ[1]. Aproveitei a função pronta do euler[2] e as mascaras que foram criadas nos links que mandei. Partiu? [1] https://github.com/guedes/validadores/pull/1 [2] https://wiki.postgresql.org/wiki/CNPJ -- Sebastian Webber http://swebber.me ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: REF: Lendo tipo Bytea
Rafael, Era exatamente isso. O pessoal do servidor remoto havia esquecido de setar para escape. Abraços. Att, Paulo. De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Rafael Fialho Enviada em: segunda-feira, 23 de novembro de 2015 16:44 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] REF: Lendo tipo Bytea Em 23 de novembro de 2015 16:34, Paulo escreveu: Olá Pessoal, Tenho um campo tipo bytea, nele gravo um conteúdo XML. Quando leio este conteúdo localmente retorna OK, porem em produção no servido web ele retorna em Hexa. Alguém pode dar uma dica ? Verifique o parâmetro bytea_output de ambos os servidores. Creio que sejam servidores/clusters distintos, correto? O comando pode ser executado via psql mesmo: show bytea_output; Provavelmente um deles deve ser escape e o outro hexa. Vale checar também as versões, pois não tenho certeza de qual delas implementa o output em hexadecimal como default. []'s ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] REF: Lendo tipo Bytea
Em 23 de novembro de 2015 16:34, Paulo escreveu: > Olá Pessoal, > > > > Tenho um campo tipo bytea, nele gravo um conteúdo XML. > Alguma razão em especial pra não utilizar o tipo de dados xml[1]? Creio que seja mais simples trabalhar com o tipo de dados específico. [1] http://www.postgresql.org/docs/9.4/static/datatype-xml.html -- Sebastian Webber http://swebber.me ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
