Re: [pgbr-geral] Nova lista PGBR
2018-04-19 10:17 GMT-03:00 Rafael Fialho : > Eu tenho filtros com todas as condições possíveis e não estão funcionando.. > o valor do campo seria "pgsql-pt-geral"? No gmail tem uma ação um pouco escondida "filtrar mensagens como esta". Selecionando ela, o gmail abre o formulário de criar filtros com o campo "inclui as palavras" já preenchido com: list:"pgbr-geral@listas.postgresql.org.br" ou list:"pgsql-pt-ge...@lists.postgresql.org" (o que filtra pelo campo List-Id do cabeçalho das mensagens SMTP). Recomendo usar esse método em vez de inventar o filtro por conta própria. Tureba - Arthur Nascimento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Campo calculado
2018-04-18 8:29 GMT-03:00 Rogério Martins :
> Bom dia pessoal !
>
> É possível criar no PG 9.6 um campo calculado ?
> Exemplo:
>
> select
> t.data_nascimento,
> t.campo_calculado_idade,
> from tabela t
>
> onde:
> t.campo_calculado_idade = date_part('year', age(t.data_nascimento) )
>
> Não quero usar view, preciso desse campo na tabela.
Sim. A longo prazo, o que você procura é GENERATED COLUMNS, que está
no padrão SQL. Infelizmente não vai entrar nem na v11, mas quem sabe
no futuro. Recomendo dar uma lida na thread de e-mail daqui: [1]
Mas além dos triggers que já disseram aqui, tem um outro truque
abusando da resolução de funções no postgres. É descrito na primeira
resposta da thread principal da feature.
[1] https://commitfest.postgresql.org/17/1443/
Tureba - Arthur Nascimento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Update em campo do tipo date array
2018-01-16 13:15 GMT-02:00 Edelson Regis de Lima : > Boa tarde pessoal. > > Estou apanhando um pouco para dar um Replace em uma data dentro de um campo > do tipo date[] Use array_replace(), array_remove() e todas as outras opções para trabalhar diretamente com arrays. Não fique convertendo para texto. https://www.postgresql.org/docs/current/static/functions-array.html Tureba - Arthur Nascimento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Comparação de imagens
On Mon, Nov 13, 2017 at 8:37 AM Artur Zanini wrote: > Eu preciso comparar 200K fotos dividas em 4 tabelas. Precisos descobrir > fotos que possivelmente podem ser iguais, talvez uma acurácia de 90% > Alguma sugestão? > Tente isso: https://github.com/postgrespro/imgsmlr -- Arthur Nascimento - tureba ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Remover caracteres escondido
On Fri, Aug 18, 2017 at 11:03 AM Zan wrote: Douglas, no meu caso não deu certo. Este bendito caractere (\342\200\213) é uma "?". Acho que o que você quer é esconder os caracteres não imprimíveis da saída: select regexp_replace(atributo, '[^[:print:]]', '') from tabela; -- Arthur Nascimento - tureba ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configuração de Máquina
>> Nesse ponto eu prefiro centos/rhel (pela documentação e suporte da >> RH) > Lembrando que a Red Hat não suporta o CentOS, e que além da comunidade > há várias empresas que suportam Debian — o que vale também para os > *BSDs, em menor grau. Não diretamente, mas você consegue colocar a subscription num centos, fazer uma troca dos repositórios e reinstalar os pacotes relevantes (não precisa nem trocar todos). Se mostrar para eles que no final o sistema sofre do mesmo problema com os pacotes deles, eles seguem o case e resolvem o problema. Só não anunciam porque não vale a pena para eles seguir esse caminho longo; mas é possível e te economiza subscriptions enquanto o centos não der problema. >> (Pessoalmente eu prefiro distros source based e rolling release, mas >> profissionalmente é outra história.) > O Debian testing funciona como atualizações contínuas (/rolling > release/), e todas as livres (o que exclui o Red Hat) são baseadas em > código-fonte — mas as que compilam na instalação dão uma dor de cabeça > pequena, mas ainda desproporcional aos benefícios, esses sim ínfimos. > De qualquer maneira, em produção quer-se estabilidade, o que exclui > atualizações contínuas. Sim, é fato bem conhecido que não vale a pena compilar o sistema inteiro em cada instalação. Mas em praticamente toda distro source based também tem como compilar uma vez e disponibilizar os binários em um repositório privado (ou mesmo público, mas não-oficial). Fiz bastante disso em clusters HPC, em que qualquer pequeno ganho é importante. Compila uma vez e usa em centenas de nós. Mas isso já faz tempo. Hoje só tenho poucas máquinas parecidas na nuvem, mas pessoalmente os benefícios de manter elas ainda são bem grandes para mim: eu fico sempre atualizado com release notes e changelogs dos pacotes que mais me afetam; às vezes encontro bugs, reporto e tento corrigir. É divertido também. Mas como eu disse antes, profissionalmente, recomendo centos e rhel, dependendo de cada caso. BTW, sabe que as fontes da red hat são públicas, certo? Não são livres no sentido legal, mas públicas sim, estão no ftp da red hat e qualquer um pode baixar. Os binários é que não são nem públicos e menos ainda livres. Não sei bem o que você quis dizer excluindo a red hat, então só comentei para não faltar. -- Arthur Nascimento - tureba ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configuração de Máquina
>> * vocês sabem qual a melhor distribuição Linux usar para o >> postgresql. A melhor é aquela que você (ou a sua equipe) domina. É difícil ser melhor que isso, já que a distro não faz nada por si só. Em segundo lugar, olhe também para a política de atualizações de cada uma: bugfixes críticos precisam chegar em questão de poucas horas nas máquinas de produção e, quando possível, automaticamente; enquanto que atualizações com features novas ou mudanças maiores precisariam passar por aprovação/homologação/validação/etc de vocês. Se a distro não tiver políticas desses dois casos bem definidas você (na verdade a sua empresa) vai estar correndo riscos em um ou nos dois lados. Nesse ponto eu prefiro centos/rhel (pela documentação e suporte da RH), mas muita gente apoia debian/ubuntu. E BSDs são excelentes também, mas eu conheço bem menos deles. (Pessoalmente eu prefiro distros source based e rolling release, mas profissionalmente é outra história.) >> * temos que nos preocupar com mais alguma coisa? > Muitas. Bases de dados não são triviais. [...] Muitas mesmo. Anos atrás eu encontrei o PostgreSQL High Performance 9.0 do Gregory Smith. Os primeiros capítulos descrevem em muitos detalhes todos os aspectos importantes nessa escolha (memória, processamento, I/O, benchmarks etc), então eu recomendo muito ele como um começo. Parece que esse ano saiu a versão atualizada para o 9.6, que eu não li ainda, mas se seguir a linha da anterior, então vale a pena o investimento. Boa sorte, -- Arthur Nascimento - tureba ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL com Docker
04.07.2017, 20:18, "Lucas Viecelli" : > Alguém utiliza o PostgreSQL com Docker em um ambiente de produção? Tenho alguns serviços ainda com docker em produção, mas me arrependi disso já faz tempo e estou gradualmente mudando isso. O docker tem vários problemas com algumas coisas que são importantes para os meus ambientes (mas talvez não seja para o seu), como selinux (exigido por algumas auditorias) e ipv6. Mesmo nas coisas mais simples, ele consegue causar mais trabalho do que resolve, como quando embaralha as regras dos meus firewalls para fazer o NAT funcionar no bridge entre os containers (o que é tudo completamente desnecessário quando usando ipv6, se ele usasse endereços do escopo certo para redes locais: link-local e realm-local, por exemplo). E quando ele tenta mapear volumes inteiros na memória virtual do dockerd (se eu não me engano, ele faz um monte de mmap MAP_PRIVATE, sob copy-on-write, que precisa de espaço caso aconteça o write) e falha com "falta de memória" por causa do overcommit_memory=2 (mesmo com muitos GBs efetivamente livres na RAM) não é legal. E isso eu nem falei dele com o Postgres ainda. Concordando com o Leonardo e indo mais além, eu também preciso fazer muitas configurações de kernel para memória, rede e outros I/Os variados (parâmetros de SAN, por exemplo) nos servidores de banco de dados. E não dá para fazer isso só com o docker (nem com swarm+machine, se eu não me engano). Pior que isso, alguns parâmetros do Postgres atrapalham o docker e vice-versa (exemplo foi o overcommit_memory, que me obrigou a colocar swap desnecessariamente exagerados só para conseguir fazer o docker-pull de imagens gordas; também tem outro de ipv6 que eu não lembro agora). E tem inicialização de clusters, de tablespaces, configurações de replicação, de backup etc. Basicamente a única utilidade de um Postgres em docker seria para entregar o executável cru porque todo o resto precisaria ser feito por fora dele. E já que essa é a situação, então um repositório rpm/deb/apk junto com systemd/upstart faz isso melhor que o docker hoje em dia para ambiente produtivo. E as configurações externas viriam de um ansible/chef/puppet, que fica mais adequado para isso mesmo. Então recomendo algo parecido com o que o Leonardo disse: colocar o banco em uma (ou mais, claro) máquina própria, bare metal ou virtualizada. E deixar o docker só para as outras partes da sua solução, em máquinas diferentes. É o que eu tenho feito ultimamente, depois de passar pelo vale de desilusão do hype (mas admito que a mão está coçando para ir para o próximo hype e substituir os meus dockers por rkt). Agora, se a conversa for sobre ambientes para testes, então o docker pode ajudar bastante. Criar um container com o Postgres, já com um cluster interno inicializado e com um banco de dados carregado com dados de testes ajuda muito os desenvolvedores que souberem colocar a aplicação deles em um container e subir os dois localmente por um docker-compose. Mas desses dois containers, eu só levaria o da aplicação para produção, se muito. Boa sorte, -- Arthur Nascimento - tureba ___ 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: SQL Select
>Em 23/06/2017, Ricardo escreveu: >> Usando select não vou conseguir, vou trabalhar com um função para seguar >> nesse resultado abaixo. Consegue sim. Você pode usar a window function lag() para acessar dados de janelas passadas. Mas... On Fri, Jun 23, 2017 at 1:31 PM Osvaldo Kussama wrote: > Mas isto tem algum sentido? ...concordo que está parecendo estranho. Melhor parar e pensar no resultado que você quer alcançar antes de continuar tentando escrever o select na tentativa-e-erro. -- Arthur Nascimento - tureba ___ 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: SQL Select
On Fri, Jun 23, 2017 at 9:55 AM Ricardo wrote: > Na verdade vou precisar que me retorne o saldo de cada mês ficando assim Assim é mais tranquilo ainda porque nem precisa de window function; aggregate function já resolve: #select teste.mes, sum(v_entrada) as entrada, sum(v_saida) as saida, sum(v_entrada) - sum(v_saida) from teste group by mes order by 1; mes | entrada | saida | ?column? -+-+---+-- 1 | 100 | 200 | -100 2 | 150 | 230 | -80 3 | 200 | 0 | 200 (3 rows) -- Arthur Nascimento - tureba ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SQL Select
On Thu, Jun 22, 2017 at 3:10 PM Ricardo wrote: > Estou quebrando a cabeça aqui pra criar um select que calcule o Resultado de entrada e saída da tabela abaixo sem tem que criar uma função. Será possível ? Sim, com uma window function: #select teste.*, sum(v_entrada) over w - sum(v_saida) over w from teste window w as (partition by teste.mes); tipo | mes | v_entrada | v_saida | ?column? --+-+---+-+-- E| 1 | 100 | 0 | -100 S| 1 | 0 | 200 | -100 E| 2 | 150 | 0 | -80 S| 2 | 0 | 230 | -80 E| 3 | 200 | 0 | 200 S| 3 | 0 | 0 | 200 (6 rows) Essa apresentação sobre window functions do Bruce Momjian é uma leitura adicional muito boa: https://momjian.us/main/writings/pgsql/window.pdf -- Arthur Nascimento - tureba ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Agrupar bancos de dados replicado num único Banco
On Tue, Jun 20, 2017 at 7:26 PM Ivanelson Nunes wrote: > Então como juntar esses bancos num único banco? E claro mantendo a consistência e o dado sempre atualizado. Qual a sua intenção por trás desse "juntar"? Se quiser que os dados estejam replicados em um local só, os outros ramos desta thread já falam de opções boas sobre replicação lógica. Mas também tem a chance de você só estar querendo que eles estejam *acessíveis* através de um banco único. Se for só isso, fica até mais simples: faça um banco novo, um schema para cada loja, sendo que cada um contém foreign tables para as respectivas tabelas dessas suas replicações locais. Assim você consegue consultar em um banco só loja1.tabela1, loja1.tabela2, ... loja2.tabela1, loja2, tabela2 Em cima disso eu criaria visões com union all para ajudar as suas consultas, assim as tuplas ficam todas "juntas" e marcadas com as suas respectivas procedências: create view public.tabela1 as select 'loja1', tabela1.* from loja1.tabela1 union all select 'loja2', tabela1.* from loja2.tabela1 union all Ajuste os nomes dos schemas adequadamente se tiver mais de um sendo usado nas lojas e/ou se não estiver usando o public. E visões materializadas podem ser úteis também. Boa sorte -- Arthur Nascimento - tureba ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Regressão linear, derivadas no postgres
Você provavelmente está querendo o MADlib: https://madlib.incubator.apache.org/ Pessoalmente eu nunca usei, mas a documentação é boa. Por exemplo, a página falando de regressão linear: https://madlib.incubator.apache.org/docs/latest/group__grp__linreg.html#examples Boa sorte On Mon, May 8, 2017 at 4:16 PM Artur Zanini wrote: > Boa tarde, pessoal. > > Alguém pode indicar exemplos e material como o postgres trabalha Regressão > linear. > > Funções matemáticas para Data Mining. > > Alguém já trabalhou com Data Mining usando o Postgis? > > > Desde já agradeço. > > = > Ass.: > Artur Gnecco Zanini > Fone.: 51 92232129 <(51)%209223-2129> > Gtalk: artur.zan...@gmail.com > = > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Arthur Nascimento - tureba ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Arredondamento
On Mon, Mar 13, 2017 at 10:14 AM Leandro Guimaraens Faria Corcete DUTRA < l...@dutras.org> wrote: Le lun. 13 mars 2017 à 9:55, Flavio Henrique Araque Gurgel a écrit : >> >> > Porém estão me pedindo para arredondar para acima somente >> > quando for acima de 5, por exemplo: >> >> Essa mesma é a definição e o exemplo de round (): > > Eu também levei um minuto pra entender. > O OP precisa no exemplo que o valor na próxima casa após o > arredondamento seja "acima de 5". Parece que o OP quer o arredondamento [1] "half down" ou o "half towards zero", enquanto que o round() implementa o "half away from zero" para numeric e "half to even" para ponto flutuante [2]. Talvez fosse interessante que a doc do round() explicasse melhor o "nearest integer" porque a Wikipedia fala de 6 opções diferentes de "nearest integer" e quem chega em [3] procurando essa função não percebe com facilidade que deveria ler junto com o último parágrafo de 8.1.2 [2]. [1] https://en.wikipedia.org/wiki/Rounding#Comparison_of_rounding_modes [2] https://www.postgresql.org/docs/current/static/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL [3] https://www.postgresql.org/docs/current/static/functions-math.html -- Arthur Nascimento - tureba ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] ORDER BY errado
> > Ou: > alter collation "pt_BR" set variant to 'shifted'; > Pensando melhor, esqueça o alter, que era uma péssima ideia por várias razões, e considere algo como: create database foobar lc_collate = "pt_BR-ka-shifted.UTF8" template "template0"; Aí sim faria sentido. -- Arthur Nascimento - tureba ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] ORDER BY errado
> > Alguém sabe porque o comportamento natural deste encoding já não é este? O padrão Unicode estabelece inicialmente que espaços e pontuação têm esse comportamento nas comparações [1] em todas as línguas - não só no português. Teste com outras línguas e vai ver o mesmo resultado: select * from teste2 order by nome collate "en_US"; Mas ele também dá diversos parâmetros para customizarmos os resultados. Por exemplo, as variantes "shifted" e "noignore" devem resolver a questão. Infelizmente o Postgres não nos dá acesso a nenhuma variante, então teste pela linha de comando colocando um arquivo de texto com aqueles nomes e ordenando: % LC_COLLATE=pt_BR sort http://unicode.org/reports/tr10/ [2] http://unicode.org/faq/collation.html [3] http://unicode.org/reports/tr35/tr35-collation.html <http://www.unicode.org/reports/tr35/tr35-collation.html> [4] http://unicode.org/reports/tr35/ Até mais, -- Arthur Nascimento - tureba ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Plpgsql function Postgres 9.5
> > Consegui resolver da seguinte forma: > > BETWEEN > ''' || date_start || ''' > AND > ''' || date_end || ''' > Não, nunca concatene dados para formar comandos (especialmente do lado da aplicação). É assim que sql injections nascem e você só descobre quando já é tarde demais. Mas se você insistir nisso, então pelo menos use a função quote_nullable (ou pode usar quote_literal se tiver alguma garantia de not null na origem do dado, como é o caso de date_start): [...] BETWEEN ' || quote_literal(date_start) || ' AND ' || quote_nullable(date_end) || ' [...] Mas o que você realmente quer é colocar essas variáveis na cláusula USING do EXECUTE [1]: EXECUTE $ex1$ COPY ( [...] WHERE logtime BETWEEN $1 and $2 ) [...] $ex1$ USING date_start, date_end; Ou com format [2]: EXECUTE format($fmt1$ COPY ( [...] WHERE logtime BETWEEN %L AND %L [...] $fmt1$, date_start, date_end); E domine o dollar quoting [3], que é o recomendado [4], assim você não se perde em blocos grandes e aninhados e tudo fica mais legível. [1] https://www.postgresql.org/docs/current/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN [2] https://www.postgresql.org/docs/current/static/functions-string.html#FUNCTIONS-STRING-FORMAT [3] https://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING [4] https://www.postgresql.org/docs/current/static/plpgsql-development-tips.html#PLPGSQL-QUOTE-TIPS Boa sorte -- Arthur Nascimento - tureba ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
