Re: [pgbr-geral] Registrando tempo de "downtime" para efeito de SLA

[Alexsander Rosa]

Em 5 de março de 2018 17:10, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

> Nesse caso somente olhando os logs mesmo...
>

Bom, copiei manualmente dos logs e fiz o INSERT à mão, estes primeiros
meses de 2018 ficaram assim:

rednaxel-server:rnge4=> SELECT * FROM vw_webservice_level WHERE servico =
'postgresql' ORDER BY ano, mes;
  servico   | ano  | mes | downtime | dias | segundos | svc_lvl
+--+-+--+--+--+--
 postgresql | 2018 |   1 |  22.4383 |   31 |  2678400 |  99.9992
 postgresql | 2018 |   2 |   0. |   28 |  2419200 | 100.
(2 rows)

Em março ainda não houve *downtime* mas já vi que o servidor está pedindo
reboot... Daí eu procuro no log, sem problemas.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Registrando tempo de "downtime" para efeito de SLA

[Alexsander Rosa]

Em 5 de março de 2018 15:43, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

>
> Pensando melhor sobre o seu caso, vc consegue sim obter ambas informações:
>
> 1) Se o servidor estiver online vc executa a pg_postmaster_start_time()
>
> 2) Se o servidor estiver offline entao vc pode pegar o valor de
> 'pg_control last modified:' no pg_controldata, ex:
>
> $ pg_controldata -D ~/.pgvm/clusters/10.1/main | grep -E '(Database
> cluster state|pg_control last modified)'
> Database cluster state:   shut down
> pg_control last modified: Seg 05 Mar 2018 15:40:18 -03
>
>
Estou usando o *pg_postmaster_start_time*(), criei um indicador "Uptime PG"
no dashboard. Para uma parada controlada dá pra usar o *pg_controldata* pra
ver o *last_modified* mas o caso de uso mais comum é a reinicialização do
S.O. para atualizações, geralmente fora do horário comercial.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Registrando tempo de "downtime" para efeito de SLA

[Alexsander Rosa]

Obrigado pela resposta! Neste caso eu vou ter que fazer um polling, certo?
Eu gostaria de uma precisão abaixo de 1 minuto (ou seja, não dá pra usar o
CRON), porém não quero ficar toda hora chamando o *pg_isready* pois isso
certamente vai influenciar na carga do servidor. Além disso, quando o S.O.
for reiniciado meu programa em C vai cair também.

O ideal seria uma função análoga à *pg_postmaster_start_time()* porém com o
último shutdown.
Talvez seja possível criar uma "*pg_postmaster_last_shutdown()*" para obter
esta informação.

Eu sei que nosso servidor PG foi reiniciado, pela última vez, dia 30 de
janeiro:

SELECT pg_postmaster_start_time();
   pg_postmaster_start_time
---
 2018-01-30 07:33:29.438349-02
(1 row)

No caso eu sei que está no ar desde Janeiro porém eu não sei que horas, no
dia 30/01, o servidor foi parado. Olhando no log temos:
2018-01-30 07:33:07.278 -02 [1212] LOG:  autovacuum launcher shutting down
2018-01-30 07:33:07.373 -02 [1209] LOG:  shutting down
2018-01-30 07:33:07.440 -02 [1195] LOG:  database system is shut down
2018-01-30 07:33:29.439 -02 [1350] LOG:  database system was *shut down at
2018-01-30 07:33:07 -02*

Veja que o servidor SABE que o shutdown ocorreu às 2018-01-30 07:33:07 -02
(no caso foi uma alteração no .conf).
Resta saber se esta informação está ficando gravada em algum lugar (além do
texto do log) e como recuperá-la.


Em 5 de março de 2018 14:13, Euler Taveira <eu...@timbira.com.br> escreveu:

> Em 5 de março de 2018 12:10, Alexsander Rosa
> <alexsander.r...@gmail.com> escreveu:
> > Existe alguma forma "oficial" de obter os horários de start / stop do
> > servidor PostgreSQL sem ter que procurar string no log?
> >
> pg_isready com versões >= 9.3. Se você usa uma versão mais antiga,
> você ainda pode compilar o código do pg_isready na versão antiga ou
> fazer um programa em C que use PQpingParams() ou PQping() -- tais
> funções estão disponíveis a partir da versão 9.1.
>
>
> --
>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




-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Registrando tempo de "downtime" para efeito de SLA

[Alexsander Rosa]

Nosso servidor roda 24x7 porém de tempos em tempos (geralmente num domingo)
o pessoal da operação faz um restart por causa de atualizações do S.O.
(Linux). Eu gostaria de medir este downtime para criar um indicador do SLA
(ex: 99,999% de uptime) separado somente para o PostgreSQL, que é diferente
do downtime dos (micro) serviços.

Existe alguma forma "oficial" de obter os horários de start / stop do
servidor PostgreSQL sem ter que procurar string no log?

Por exemplo, meu desktop aqui tem um PG 9.6 que ao ser reiniciado gera o
seguinte LOG:

2018-03-05 12:02:16.535 -03 [1597] LOG:  pedido de desligamento rápido foi
recebido
2018-03-05 12:02:16.535 -03 [1597] LOG:  interrompendo quaisquer transações
ativas
2018-03-05 12:02:16.535 -03 [1698] LOG:  inicializador do autovacuum está
sendo desligado
2018-03-05 12:02:16.536 -03 [1695] LOG:  desligando
2018-03-05 12:02:16.705 -03 [1597] LOG:  sistema de banco de dados está
desligado
2018-03-05 12:02:17.737 -03 [6814] LOG:  sistema de banco de dados foi
desligado em 2018-03-05 12:02:16 -03
2018-03-05 12:02:17.785 -03 [6814] LOG:  MultiXact member wraparound
protections are now enabled
2018-03-05 12:02:17.787 -03 [6813] LOG:  sistema de banco de dados está
pronto para aceitar conexões
2018-03-05 12:02:17.787 -03 [6818] LOG:  inicializador do autovacuum foi
iniciado

Seria interessante se houvesse algum tipo de gatilho onde eu pudesse gravar
isso de forma controlada.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] "orientado a banco de dados"

[Alexsander Rosa]

Nosso ERP tem 385 stored procedures, a maior delas atende o WMS e roda na
madrugada, gerando automaticamente centenas de pedidos no CD que serão
depois separados e expedidos para as filiais (nosso maior cliente tem 20
delas). Temos várias outras que fazem tarefas complexas como "Importar
XML", que recebe o XML de uma NFe do fornecedor e cria os registros nas
diversas tabelas relevantes, incluindo no contas a pagar.

Uma grande vantagem é poder chamar as procedures por diversos aplicativos,
desde clientes desktop (versões antigas do ERP), REST API + aplicações web
/ PWA (versão nova do ERP e WMS novo) e aplicativos console que rodam via
SSH (WMS versão antiga).

Controlamos o versionamento via GIT usando um shell script:
https://github.com/rednaxelbr/scripts
O script "gera_pgfunc" gera um arquivo "nome-da-procedure.sql" para cada SP
usando a pg_get_functiondef() do PostgreSQL.



Em 3 de janeiro de 2018 10:13, Samuel Teixeira Santos 
escreveu:

> Bom dia pessoal, feliz 2018 a todos.
>
> Sou novo na lista e meu perfil é de desenvolvedor (para entenderem o
> porque da minha pergunta abaixo... tentando justificá-la )
>
> Estou na faixa de conhecimento que vai do básico para intermediário em
> relação a banco de dados e me interesso mais pela perfil técnico de banco
> de dados do que da modelagem/administração de dados.
>
> Por isso, gostaria de bater um papo, ler o que vocês sabem ou acham sobre
> casos, se já viram algum, em que foi-se construída uma aplicação que tinha
> toda sua inteligência no banco de dados, podendo facilitar a desacoplagem
> da camada do cliente de forma menos trabalhosa e associando a outras
> tecnologias desta camada conforme a necessidade.
>
> Já viram algo do tipo? Recomendam tal abordagem?
>
> Por exemplo, hoje uma aplicação WEB, você desenvolve a camada
> cliente(browser: html/css/js), desenvolve o backend (apache/nginx/tomcat -
> php/python/java) e ainda mais específico, a camada do banco de dados.
>
> A idéia é continuar desenvolvendo a camanda cliente (porque não há como
> fugir dela no casa da plataforma web), mas minimizar o possível a camada do
> server, deixando-a apenas para o repasse de dados para o banco e a chamada
> de procedures e functions no mesmo, onde realmente existirá o processamento
> total dos dados, as regras de negócio etc
>
> Na experiência de vocês, já viram algo? Já tentaram algo do tipo?
>
> O que acham desta abordagem?
>
> Chamei-a no título de "orientado a banco de dados" com aspas porque
> realmente não sabia como titular de outra forma menos redundante, ou com
> pleonasmo, não sei.
>
> Espero poder muito aprender com vocês, independente do que eu expus aqui
> ser viável ou não.
>
> Abraço a todos.
>
>
> Samuel
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Atenciosamente,
Alexsander da Rosa
___
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 descobrir se uma procedure foi modificado no postgresql

[Alexsander Rosa]

Eu coloco no GIT/SVN usando um script simples chamado *gera_pgfunc*:
https://github.com/rednaxelbr/scripts

Ele gera no diretório atual um arquivo (com o conteúdo do CREATE OR REPLACE
FUNCTION ...) para cada stored procedure do banco informado. Requer
configuração do pg_hba (ou .pgpass) para funcionar, ou pode-se passar a
senha com uma alteração trivial.

Assim temos como controlar não apenas se foi modificada mas quem modificou
e quando.


Em 18 de novembro de 2017 23:59, Amir  escreveu:

> Boa noite...
>
> Com saber se uma procedure foi modificada, no banco
>
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

[Alexsander Rosa]

Em 28 de junho de 2017 22:57, Ronaldo Bernardes Pereira <
ronaldobernar...@gmail.com> escreveu:

> --===   Como acredito que você irá resolver seu problema, seque
> considerações
>
> O problema encontrado é que o PostgreSQL fez um CAST da coluna (gn)
> (Filter: ((gn)::text = '900'::text)) para atender o tipo de argumento
> da FUNCTION que era do tipo text e no caso a coluna que ele comparava era
> do tipo char. Como o tamanho do campo tipo text pode ser muito maior do que
> um campo tipo char,  houve então o CAST implícito pelo PostgreSQL e com
> isso única alternativa que ele tinha nesse caso era fazer um seq scan, pois
> o índice não atendia para esse caso.
>
> --=== -->> Sugestões:
>
> 1 - Qual o tipo da coluna nfce_chave_acesso_fk e chave_acesso para
> entender melhor o problema?
>

Ambas são VARCHAR(44), esta é a chave de acesso de uma Nota Fiscal
Eletrônica (NFe e NFCe).


> 2 - Colocar o tipo do argumento da FUNCTION com o mesmo tipo da coluna,
> para não ocorrer CAST implícito das colunas nfce_chave_acesso_fk ou
> chave_acesso
>

Vamos fazer esta alteração, a procedure "sp_importa_xml_nfce" é nova e
ainda não está em produção.


> 3 - Caso não tenha como mudar (...)
> 4 - Executar e nos passar o resultado
>

Sim, testei aqui na "sp_teste" e funcionou. Muito obrigado! Em breve vamos
retomar o desenvolvimento do aplicativo Golang que consome a
"sp_importa_xml_nfce" e poderemos dar um retorno mais preciso.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

[Alexsander Rosa]

Em 2 de junho de 2017 16:40, Matheus de Oliveira 
escreveu:

> Isso aí pra mim tá com cara de plano de execução genérico. Mas pra ter
> certeza seria legal você instalar e habilitar o auto_explain, daí você
> configura `auto_explain.log_nested_statements = on`  e executa a função
> novamente, ele vai logar o plano de execução só daquela consulta no log.
>
> postgres=# SELECT sp_teste('43170605563868000113657010
> 04061895261728');
> ...  ...
>
>
O banco um Seq Scan... ignorou o índice.

central-rd540:5432:rnge2=# SELECT
sp_teste('4317060556386800011365701004061895261728');
LOG:  duration: 1810.362 ms  plan:
Query Text: SELECT num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
chave
Seq Scan on cf_cupom  (cost=0.00..305178.52 rows=54145 width=4) (actual
time=1806.082..1810.358 rows=1 loops=1)
  Filter: ((nfce_chave_acesso_fk)::text =
'4317060556386800011365701004061895261728'::text)
  Rows Removed by Filter: 10793976
LOG:  duration: 1834.088 ms  plan:
Query Text: SELECT sp_teste('4317060556386800011365701004061895261728');
Result  (cost=0.00..0.26 rows=1 width=0) (actual time=1834.080..1834.080
rows=1 loops=1)
 sp_teste
--
 OK


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

[Alexsander Rosa]

Em 2 de junho de 2017 14:34, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

>
> Em 2 de junho de 2017 12:32, Alexsander Rosa <alexsander.r...@gmail.com>
> escreveu:
> > (...)
> > Coloquei STABLE e não mudou nada:
> >
>
> Roda o ajuste abaixo (além do STABLE) e roda novamente o teste:
>
> ALTER FUNCTION sp_teste(text) COST 10;
>
>
laboratorio:rnge2=# *ALTER FUNCTION sp_teste(text) COST 10;*
ALTER FUNCTION
laboratorio:rnge2=# *EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT
sp_teste('4317060556386800011365701004061895261728');*
QUERY PLAN

--
 Result  (cost=0.00..0.04 rows=1 width=0) (actual time=1494.473..1494.473
rows=1 loops=1)
   Buffers: shared hit=18939 read=123331
 Total runtime: 1494.496 ms
(3 rows)

laboratorio:rnge2=# *SELECT pg_get_functiondef('sp_teste'::regproc);*
  pg_get_functiondef
---
 CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)  +
  RETURNS text+
  LANGUAGE plpgsql+
  STABLE COST 10  +
 AS $function$+
 DECLARE  +
 BEGIN+
   PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;+
   Return 'OK';   +
 END; +
 $function$   +

(1 row)

Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

[Alexsander Rosa]

2017-06-02 11:50 GMT-03:00 Flavio Henrique Araque Gurgel :

> Para de bagunça a lista, pelamor.
> A gente responde LÁ EMBAIXO ! olha só:
>

Coloquei STABLE e não mudou nada:
EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT
sp_teste('4317060556386800011365701004061895261728');
QUERY PLAN

--
 Result  (cost=0.00..0.26 rows=1 width=0) (actual time=1478.944..1478.944
rows=1 loops=1)
   Buffers: shared hit=18731 read=123491
 Total runtime: 1478.955 ms
(3 rows)

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

[Alexsander Rosa]

laboratorio:rnge2=# EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT num_cupom
FROM cf_cupom WHERE nfce_chave_acesso_fk =
'4317060556386800011365701004061895261728';
QUERY PLAN

--
 Index Scan using idx_cupom_chave on cf_cupom  (cost=0.55..8.57 rows=1
width=4) (actual time=0.078..0.079 rows=1 loops=1)
   Index Cond: (nfce_chave_acesso_fk =
'4317060556386800011365701004061895261728'::bpchar)
   Buffers: shared hit=5
 Total runtime: 0.106 ms
(4 rows)


2017-06-02 11:28 GMT-03:00 Alexsander Rosa <alexsander.r...@gmail.com>:

> laboratorio:rnge2=# EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT sp_teste('
> 4317060556386800011365701004061895261728');
> QUERY PLAN
>
> 
> --
>  Result  (cost=0.00..0.26 rows=1 width=0) (actual time=1523.013..1523.013
> rows=1 loops=1)
>Buffers: shared hit=18998 read=123619 dirtied=3
>  Total runtime: 1523.043 ms
> (3 rows)
>
>
> Em 2 de junho de 2017 11:11, Alexsander Rosa <alexsander.r...@gmail.com>
> escreveu:
>
>> laboratorio:rnge2=# SELECT sp_teste('43170605563868000113
>> 65701004061895261728');
>>  sp_teste
>> --
>>  OK
>> (1 row)
>>
>> Time: 1507,688 ms
>> laboratorio:rnge2=#
>>
>> 
>> -- Código "pelado"
>> CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)
>>  RETURNS text
>>  LANGUAGE plpgsql
>> AS $function$
>> DECLARE
>> BEGIN
>>   PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;
>>   Return 'OK';
>> END;
>> $function$
>> ;
>>
>> 
>> -- EXPLAIN:
>>
>> Index Scan using idx_cupom_chave on cf_cupom  (cost=0.55..8.57 rows=1
>> width=4)
>>   Index Cond: (nfce_chave_acesso_fk = '4317060556386800011365701
>> 004061895261728'::bpchar)
>>
>>
>> Em 2 de junho de 2017 11:06, Flavio Henrique Araque Gurgel <
>> fha...@gmail.com> escreveu:
>>
>>> Em sex, 2 de jun de 2017 às 15:55, Fabrízio de Royes Mello <
>>> fabri...@timbira.com.br> escreveu:
>>>
>>>>
>>>>
>>>> Em 2 de junho de 2017 10:46, Alexsander Rosa <alexsander.r...@gmail.com>
>>>> escreveu:
>>>> >
>>>> > A tabela tem cerca de 1 Gb:
>>>> > SELECT pg_size_pretty(pg_relation_size('cf_cupom'));
>>>> >  pg_size_pretty
>>>> > 
>>>> >  1114 MB
>>>> > (1 registro)
>>>> >
>>>> > Existe um índice UNIQUE no campo utilizado na query:
>>>> > "idx_cupom_chave" UNIQUE, btree (nfce_chave_acesso_fk) WHERE
>>>> nfce_chave_acesso_fk IS NOT NULL
>>>> >
>>>> > O campo utilizado também é FOREIGN KEY:
>>>> > "cupom_chave_nfe_fkey" FOREIGN KEY (nfce_chave_acesso_fk) REFERENCES
>>>> nfe_xml(chave_acesso) DEFERRABLE
>>>> >
>>>> > Código da procedure de teste:
>>>> > CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)
>>>> >  RETURNS text
>>>> >  LANGUAGE plpgsql
>>>> > AS $function$
>>>> > DECLARE
>>>> > BEGIN
>>>> >   RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
>>>> >   -- EXECUTE 'SELECT cod_empresa_fk FROM cf_cupom WHERE
>>>> nfce_chave_acesso_fk = $1' INTO empcupom USING chave;
>>>> >   PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;
>>>> >   RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
>>>> >   -- demora 1617 ms
>>>> >
>>>> >   PERFORM chave_acesso from nfe_xml where chave_acesso = chave;
>>>> >   RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
>>>> >   -- demora 21 ms
>>>> >
>>>> >   Return 'OK';
>>>> > END;
>>>> > $function$
>>>> > ;
>>>> >
>>>> > Comparativo:
>>>> > select sp_teste('4317060556386800011365701004061895261728');
>>>> > -- demora 1630 ms
>>>> >
>>>> > select num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
>>>> '4317060556386800011365701004061895261728';
>>>> > -- demora 11 ms
>>>> >
>>>> > Foi feito um VACUUM FULL ANALYZE na tabela.
>>>> > Alguém tem alguma dica para ajudar em nossa investigação?
>>>> >
>>>>
>>>> Faz o seguinte, remove aqueles "RAISE NOTICE" da sua PL e roda no psql
>>>> com o "\timing on"...
>>>>
>>>
>>> Ah, vou eleger 2 de junho como dia internacional da consulta lenta
>>> inexplicável... só hoje foram duas no meu trampo.
>>>
>>> Ao OP, cadê os EXPLAIN (analyze, timing, buffers) SELECT... ?
>>>
>>> []s
>>> Flavio Gurgel
>>>
>>>
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>
>>
>>
>> --
>> Atenciosamente,
>> Alexsander da Rosa
>>
>>
>
>
> --
> Atenciosamente,
> Alexsander da Rosa
>
>


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

[Alexsander Rosa]

laboratorio:rnge2=# EXPLAIN (ANALYZE, TIMING, BUFFERS) SELECT
sp_teste('4317060556386800011365701004061895261728');
QUERY PLAN

--
 Result  (cost=0.00..0.26 rows=1 width=0) (actual time=1523.013..1523.013
rows=1 loops=1)
   Buffers: shared hit=18998 read=123619 dirtied=3
 Total runtime: 1523.043 ms
(3 rows)


Em 2 de junho de 2017 11:11, Alexsander Rosa <alexsander.r...@gmail.com>
escreveu:

> laboratorio:rnge2=# SELECT sp_teste('43170605563868000113
> 65701004061895261728');
>  sp_teste
> --
>  OK
> (1 row)
>
> Time: 1507,688 ms
> laboratorio:rnge2=#
>
> 
> -- Código "pelado"
> CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)
>  RETURNS text
>  LANGUAGE plpgsql
> AS $function$
> DECLARE
> BEGIN
>   PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;
>   Return 'OK';
> END;
> $function$
> ;
>
> 
> -- EXPLAIN:
>
> Index Scan using idx_cupom_chave on cf_cupom  (cost=0.55..8.57 rows=1
> width=4)
>   Index Cond: (nfce_chave_acesso_fk = '43170605563868000113657010
> 04061895261728'::bpchar)
>
>
> Em 2 de junho de 2017 11:06, Flavio Henrique Araque Gurgel <
> fha...@gmail.com> escreveu:
>
>> Em sex, 2 de jun de 2017 às 15:55, Fabrízio de Royes Mello <
>> fabri...@timbira.com.br> escreveu:
>>
>>>
>>>
>>> Em 2 de junho de 2017 10:46, Alexsander Rosa <alexsander.r...@gmail.com>
>>> escreveu:
>>> >
>>> > A tabela tem cerca de 1 Gb:
>>> > SELECT pg_size_pretty(pg_relation_size('cf_cupom'));
>>> >  pg_size_pretty
>>> > 
>>> >  1114 MB
>>> > (1 registro)
>>> >
>>> > Existe um índice UNIQUE no campo utilizado na query:
>>> > "idx_cupom_chave" UNIQUE, btree (nfce_chave_acesso_fk) WHERE
>>> nfce_chave_acesso_fk IS NOT NULL
>>> >
>>> > O campo utilizado também é FOREIGN KEY:
>>> > "cupom_chave_nfe_fkey" FOREIGN KEY (nfce_chave_acesso_fk) REFERENCES
>>> nfe_xml(chave_acesso) DEFERRABLE
>>> >
>>> > Código da procedure de teste:
>>> > CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)
>>> >  RETURNS text
>>> >  LANGUAGE plpgsql
>>> > AS $function$
>>> > DECLARE
>>> > BEGIN
>>> >   RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
>>> >   -- EXECUTE 'SELECT cod_empresa_fk FROM cf_cupom WHERE
>>> nfce_chave_acesso_fk = $1' INTO empcupom USING chave;
>>> >   PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;
>>> >   RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
>>> >   -- demora 1617 ms
>>> >
>>> >   PERFORM chave_acesso from nfe_xml where chave_acesso = chave;
>>> >   RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
>>> >   -- demora 21 ms
>>> >
>>> >   Return 'OK';
>>> > END;
>>> > $function$
>>> > ;
>>> >
>>> > Comparativo:
>>> > select sp_teste('4317060556386800011365701004061895261728');
>>> > -- demora 1630 ms
>>> >
>>> > select num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
>>> '4317060556386800011365701004061895261728';
>>> > -- demora 11 ms
>>> >
>>> > Foi feito um VACUUM FULL ANALYZE na tabela.
>>> > Alguém tem alguma dica para ajudar em nossa investigação?
>>> >
>>>
>>> Faz o seguinte, remove aqueles "RAISE NOTICE" da sua PL e roda no psql
>>> com o "\timing on"...
>>>
>>
>> Ah, vou eleger 2 de junho como dia internacional da consulta lenta
>> inexplicável... só hoje foram duas no meu trampo.
>>
>> Ao OP, cadê os EXPLAIN (analyze, timing, buffers) SELECT... ?
>>
>> []s
>> Flavio Gurgel
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
> --
> Atenciosamente,
> Alexsander da Rosa
>
>


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

[Alexsander Rosa]

laboratorio:rnge2=# SELECT sp_teste('43170605563868000113
65701004061895261728');
 sp_teste
--
 OK
(1 row)

Time: 1507,688 ms
laboratorio:rnge2=#


-- Código "pelado"
CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)
 RETURNS text
 LANGUAGE plpgsql
AS $function$
DECLARE
BEGIN
  PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;
  Return 'OK';
END;
$function$
;


-- EXPLAIN:

Index Scan using idx_cupom_chave on cf_cupom  (cost=0.55..8.57 rows=1
width=4)
  Index Cond: (nfce_chave_acesso_fk =
'4317060556386800011365701004061895261728'::bpchar)


Em 2 de junho de 2017 11:06, Flavio Henrique Araque Gurgel <fha...@gmail.com
> escreveu:

> Em sex, 2 de jun de 2017 às 15:55, Fabrízio de Royes Mello <
> fabri...@timbira.com.br> escreveu:
>
>>
>>
>> Em 2 de junho de 2017 10:46, Alexsander Rosa <alexsander.r...@gmail.com>
>> escreveu:
>> >
>> > A tabela tem cerca de 1 Gb:
>> > SELECT pg_size_pretty(pg_relation_size('cf_cupom'));
>> >  pg_size_pretty
>> > 
>> >  1114 MB
>> > (1 registro)
>> >
>> > Existe um índice UNIQUE no campo utilizado na query:
>> > "idx_cupom_chave" UNIQUE, btree (nfce_chave_acesso_fk) WHERE
>> nfce_chave_acesso_fk IS NOT NULL
>> >
>> > O campo utilizado também é FOREIGN KEY:
>> > "cupom_chave_nfe_fkey" FOREIGN KEY (nfce_chave_acesso_fk) REFERENCES
>> nfe_xml(chave_acesso) DEFERRABLE
>> >
>> > Código da procedure de teste:
>> > CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)
>> >  RETURNS text
>> >  LANGUAGE plpgsql
>> > AS $function$
>> > DECLARE
>> > BEGIN
>> >   RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
>> >   -- EXECUTE 'SELECT cod_empresa_fk FROM cf_cupom WHERE
>> nfce_chave_acesso_fk = $1' INTO empcupom USING chave;
>> >   PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;
>> >   RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
>> >   -- demora 1617 ms
>> >
>> >   PERFORM chave_acesso from nfe_xml where chave_acesso = chave;
>> >   RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
>> >   -- demora 21 ms
>> >
>> >   Return 'OK';
>> > END;
>> > $function$
>> > ;
>> >
>> > Comparativo:
>> > select sp_teste('4317060556386800011365701004061895261728');
>> > -- demora 1630 ms
>> >
>> > select num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = '
>> 4317060556386800011365701004061895261728';
>> > -- demora 11 ms
>> >
>> > Foi feito um VACUUM FULL ANALYZE na tabela.
>> > Alguém tem alguma dica para ajudar em nossa investigação?
>> >
>>
>> Faz o seguinte, remove aqueles "RAISE NOTICE" da sua PL e roda no psql
>> com o "\timing on"...
>>
>
> Ah, vou eleger 2 de junho como dia internacional da consulta lenta
> inexplicável... só hoje foram duas no meu trampo.
>
> Ao OP, cadê os EXPLAIN (analyze, timing, buffers) SELECT... ?
>
> []s
> Flavio Gurgel
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] SELECT simples lento dentro da procedure e rápido fora dela

[Alexsander Rosa]

*A tabela tem cerca de 1 Gb:*
SELECT pg_size_pretty(pg_relation_size('*cf_cupom*'));
 pg_size_pretty

 1114 MB
(1 registro)

*Existe um índice UNIQUE no campo utilizado na query:*
"idx_cupom_chave" UNIQUE, btree (nfce_chave_acesso_fk) WHERE
nfce_chave_acesso_fk IS NOT NULL

*O campo utilizado também é FOREIGN KEY:*
"cupom_chave_nfe_fkey" FOREIGN KEY (nfce_chave_acesso_fk) REFERENCES
nfe_xml(chave_acesso) DEFERRABLE

*Código da procedure de teste:*
CREATE OR REPLACE FUNCTION rnx.sp_teste(chave text)
 RETURNS text
 LANGUAGE plpgsql
AS $function$
DECLARE
BEGIN
  RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
  -- EXECUTE 'SELECT cod_empresa_fk FROM cf_cupom WHERE
nfce_chave_acesso_fk = $1' INTO empcupom USING chave;
*  PERFORM num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk = chave;*
  RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
  -- demora 1617 ms

*  PERFORM chave_acesso from nfe_xml where chave_acesso = chave;*
  RAISE NOTICE '(%)', clock_timestamp()::timestamp(6);
  -- demora 21 ms

  Return 'OK';
END;
$function$
;

*Comparativo:*
select sp_teste('4317060556386800011365701004061895261728');
-- demora 1630 ms

select num_cupom FROM cf_cupom WHERE nfce_chave_acesso_fk =
'4317060556386800011365701004061895261728';
-- demora 11 ms

Foi feito um VACUUM FULL ANALYZE na tabela.
Alguém tem alguma dica para ajudar em nossa investigação?

-- 
Atenciosamente,
Alexsander da Rosa
___
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: SQL de Profissoes.

[Alexsander Rosa]

Seria por acaso a CBO (Classificação Brasileira de Ocupações)?
http://www.mtecbo.gov.br/cbosite/pages/downloads.jsf

Em 21 de dezembro de 2016 11:40, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> Le 21 déc. 2016 11:11, "Paulo"  a écrit :
> > Alguém conhece ou tem o link de onde posso baixar as profissões em SQL ?
>
> Poderias ser mais preciso e claro?
>
> Se for o que estou pensando, já discutimos longamente nesta lista (ou
> sua antecessora no Yahoo, creio) há alguns anos.
>
>
> --
> 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




-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramenta de DIFF para PostgreSQL

[Alexsander Rosa]

Tem 2 -d (um deles sem argumento)

Em 13 de abril de 2016 12:55, Edson F. Lidorio <ed...@openmailbox.org>
escreveu:

>
>
> On 13-04-2016 12:04, Alexsander Rosa wrote:
>
> Em 13 de abril de 2016 09:08, Edson F. Lidorio <ed...@openmailbox.org>
> escreveu:
>
>>
>> Olá Alexsander,
>>
>> Poderia postar um exemplo simples de uso, de como comparar 2 bases de
>> dados?
>>
>> Obrigado;
>>
>
> Atualizei o github (versão 1.05), coloquei um exemplo.
> Também fiz o upload dos binários Windows 32 e Linux 64.
> https://github.com/rednaxelbr/rnx-pgdiff
>
>
> --
> Atenciosamente,
> Alexsander da Rosa
>
> Não deu certo!
>
>
> lidorio@debian8-jessie:~/edinho/des/Repositorios/git/rnx-pgdiff$
> ./rnx_pg_diff -m 192.168.2.104 -u postgres -d -p fada3232* -d dbteste_dev
> -s rnx -v
>
> -- Rednaxel PostgreSQL Diff Tool - v1.05
> exception at :
> Option at position 5 needs an argument : d.
>
>


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramenta de DIFF para PostgreSQL

[Alexsander Rosa]

Em 13 de abril de 2016 09:08, Edson F. Lidorio 
escreveu:

>
> Olá Alexsander,
>
> Poderia postar um exemplo simples de uso, de como comparar 2 bases de
> dados?
>
> Obrigado;
>

Atualizei o github (versão 1.05), coloquei um exemplo.
Também fiz o upload dos binários Windows 32 e Linux 64.
https://github.com/rednaxelbr/rnx-pgdiff


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Ferramenta de DIFF para PostgreSQL

[Alexsander Rosa]

Depois de experimentar as 2 antigas (pgdiff e apgdiff) acabamos criando uma.

*rnx-pgdiff*
https://github.com/rednaxelbr/rnx-pgdiff

*Syntax: rnx_pg_diff -m IP [options]*
*  -m IP, --master=IPMaster server IP address.*
*Options:*
*  -h, --helpPrints this message.*
*  -d, --debug   Prints internal SQL queries.*
*  -v, --verbose Prints detailed output.*
*  -x, --execExecutes the DDL commands on slave.*

Os binários da release 1.04 também estão no github:
https://github.com/rednaxelbr/rnx-pgdiff/releases

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

[Alexsander Rosa]

Em termos de libpq, tem latência no PQconnectdb, no PQstatus, no PQexec,
etc... se você se conecta a um host remoto, cada ida-e-volta em cada
comando desses leva vários milissegundos. Se for um webservice você
conecta, o webservice se conecta ao PG numa LAN e faz tudo isso com uma
latência bem menor, depois te responde somente o payload. Se for um
componente "curioso" que faz uns SELECT a mais, é pior ainda.

Em 8 de março de 2016 10:53, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

> On 08-03-2016 10:38, Alexsander Rosa wrote:
> > Em 5 de março de 2016 16:10, Ali do Amaral Pedrozo <ali@gmail.com
> > <mailto:ali@gmail.com>> escreveu:
> >
> >
> > Informações gerais do ambiente onde está minha aplicação em Delphi:
> > - Windows 8.1
> > - Banda 15 MB ADSL
> >
> > Alguns testes que eu já fiz:
> > 1) no pgadmin, se eu faço select * from compra (tenho 18 campos) com
> > a tabela zerada, ele apresenta 301 ms, porém, demora 21s para exibir
> > a informação
> > 2) via psql no windows,
> > psql -h xxx.xxx.xxx.xxx -U postgres (demora 2 s)
> > \connect database (demora 2s)
> > select * from compra; (instantaneo)
> > 3) via delphi, conectando via firedac (demora 5s)
> > 4) via delphi, quando eu faço tfdquery.open (demora 5s)
> >
> >
> > Tem toda uma latência envolvida (em várias fases). Use REST.
> >
>
> Pq? O payload do REST é maior que da libpq...
>
> --
>Fabrízio de Royes Mello 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
>



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VELOCIDADE DE ACESSO REMOTO AO POSTGRESQL

[Alexsander Rosa]

Em 5 de março de 2016 16:10, Ali do Amaral Pedrozo 
escreveu:

>
> Informações gerais do ambiente onde está minha aplicação em Delphi:
> - Windows 8.1
> - Banda 15 MB ADSL
>
> Alguns testes que eu já fiz:
> 1) no pgadmin, se eu faço select * from compra (tenho 18 campos) com a
> tabela zerada, ele apresenta 301 ms, porém, demora 21s para exibir a
> informação
> 2) via psql no windows,
> psql -h xxx.xxx.xxx.xxx -U postgres (demora 2 s)
> \connect database (demora 2s)
> select * from compra; (instantaneo)
> 3) via delphi, conectando via firedac (demora 5s)
> 4) via delphi, quando eu faço tfdquery.open (demora 5s)
>
>
Tem toda uma latência envolvida (em várias fases). Use REST.



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramentas para Gerenciar Regras de negocio no banco de dados

[Alexsander Rosa]

Em 18 de janeiro de 2016 14:17, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2016-01-18 13:58 GMT-02:00 Douglas Fabiano Specht <
> douglasfabi...@gmail.com>:
> > Vamos utilizar o Postgresql 9.5 como Banco de dados Default, mas pode
> > ocorrer de termos clientes com Oracle, logo já precisamos nos preparar.
> > O que eu queria era recomendações:
> > 1-Ferramenta de modelagem multi banco e colaborativo(open-source de
> > preferencia)
>
> Eu prefiro lidar com código fonte e gerar os diagramas a partir dele.
> Para isso temos SQL::Fairy, pgAutodoc e uma terceira alternativa, mais
> moderna, cujo nome me escapa mas que algum colega logo lembrará.
>
>
SchemaSpy (veja exemplo no link abaixo):
http://schemaspy.sourceforge.net/sample/tables/book.html


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Gerar dicionário de dados

[Alexsander Rosa]

Em 16 de novembro de 2015 13:46, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

>
>> Utilizando ferramentas de terceiros, qual seria a mais indicada para
>> esta geração?
>>
>
> Precisa não.
> Mas eu deixo o Dutra te explicar melhor, ele é o mestre da documentação de
> dados, tipo, já mostrou suas astúcias mundo afora.
>
>
Atualmente usamos o *SchemaSpy*. Usávamos o *Autodoc* antes.
Acho que vale a pena, principalmente por causa dos diagramas.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Gerar dicionário de dados

[Alexsander Rosa]

Em 16 de novembro de 2015 16:02, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> > No SchemaSpy são vários arquivos, um pra cada tabela, com mais detalhes.
> > Tem até um mini-diagrama mostrando os relacionamentos mais próximos.
> > E o resultado é interativo, dá para mostrar mais ou menos detalhes.
>
> Legal, muito bom.
>
>
> > Veja esse exemplo do próprio site deles:
> > http://schemaspy.sourceforge.net/sample/tables/book.html
>
> Faz tempo que não vejo um projeto ativo no Source forge.
>
>
Não sei se dá pra chamar de ativo, o último release (5.0.0) é de 2010.
Mas funciona. :-)

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Gerar dicionário de dados

[Alexsander Rosa]

Em 16 de novembro de 2015 14:59, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2015-11-16 14:27 GMT-02:00 Alexsander Rosa <alexsander.r...@gmail.com>:
> >
> > Atualmente usamos o SchemaSpy. Usávamos o Autodoc antes.
>
> Pode explicar o que levou a abandonar um e adotar outro, para nosso
> benefício?
>
>
No autodoc são poucos arquivos enormes, a navegação é por hashtags HTML.
Os diagramas são enormes, com centenas de tabelas vira um emaranhado.
Do ponto de vista estético ele também deixa bastante a desejar.

No SchemaSpy são vários arquivos, um pra cada tabela, com mais detalhes.
Tem até um mini-diagrama mostrando os relacionamentos mais próximos.
E o resultado é interativo, dá para mostrar mais ou menos detalhes.
Veja esse exemplo do próprio site deles:
http://schemaspy.sourceforge.net/sample/tables/book.html


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [off-topic] Only NoSQL

[Alexsander Rosa]

Em 9 de novembro de 2015 01:48, Charly  escreveu:

> O grande problema na area de TI eh a falta de conceitos.
>
>
Pois é, depois de anos (décadas) integrando softwares de fabricantes
diferentes vejo que o maior problema é esse mesmo. Coisas básicas como
chaves primárias, estrangeiras, unique index, etc são pouco usadas.

Um caso recente ocorreu em um cliente cujo PDV é de terceiros. Nós
executamos *stored procedures* no BD deles para buscar os cupons fiscais;
eles recém implementaram o suporte ao cupom fiscal eletrônico e nas últimas
semanas ocorreram vários erros nessas *procedures*. Mandamos nesse período
vários emails com logs pra eles; semana passada ELES nos mandaram um email
dizendo que nosso software não estava conseguindo importar os cupons.
Inicialmente acharam que o erro era no nosso código (pois eram mensagens do
PostgreSQL), mas na verdade era um bug no código deles (de novo): por algum
motivo começaram a mandar cupons NFCe de novembro com chaves de acesso
(Sefaz) de cupons antigos, de setembro. Corrigiram a *procedure* e tudo
voltou a funcionar.

Esses cupons com erro não estavam entrando no nosso BD por causa do UNIQUE
INDEX na coluna chave de acesso. *"Ah, que sorte que vocês checam isso,
né?"* Eu não chamaria de sorte...


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consulta que não está usando índices - alguma dica? EXPLAIN incluso

[Alexsander Rosa]

Tirei a restrição do índice e funcionou... Valeu!

Em 18 de setembro de 2015 14:41, Eduardo Bohrer 
escreveu:

> Eis o índice:
>> "idx_movim_website" UNIQUE, btree (ecommerce_orderid_fk) WHERE
>> ecommerce_orderid_fk IS NOT NULL
>>
>
> Posso estar falando bobagem.
>
> Mas acho que o fato de seu índice ser condicional (WHERE
> ecommerce_orderid_fk IS NOT NULL) está invalidando ele para esta query
> pois a restrição não está explícita na query. (apesar de implicitamente o
> join equivaler)
>
> Tente adicionar a clausula (WHERE ecommerce_orderid_fk IS NOT NULL) na
> query ou tirar esta restrição do índice e veja se começa a utilizar.
>
> Att;
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Consulta que não está usando índices - alguma dica? EXPLAIN incluso

[Alexsander Rosa]

A tabela "movimento" (com todos os pedidos) tem um milhão de registros.
Destes, umas poucas dezenas têm "ecommerce_orderid_fk" não-nulo:

SELECT count(*) FROM movimento WHERE ecommerce_orderid_fk is not null;
 count
---
35
(1 row)


Eis o índice:
"idx_movim_website" UNIQUE, btree (ecommerce_orderid_fk) WHERE
ecommerce_orderid_fk IS NOT NULL

Eis o comando SQL:

EXPLAIN ANALYZE
SELECT ecommerce_orderid as order_id, data_criacao, state_etapa as state,
status_situacao as status, cod_tipomov_fk as tipo, num_orcamento_fk as
numped, valor_total, status_atual as st
FROM website_pedido LEFT OUTER JOIN movimento
ON (ecommerce_orderid = ecommerce_orderid_fk);


Eis o Explain Analyze:
QUERY PLAN

---
 Hash Left Join  (cost=71252.85..84184.09 rows=188766 width=99) (actual
time=2114.078..2114.333 rows=35 loops=1)
   Hash Cond: (website_pedido.ecommerce_orderid =
movimento.ecommerce_orderid_fk)
   ->  Seq Scan on website_pedido  (cost=0.00..1.35 rows=35 width=80)
(actual time=0.005..0.023 rows=35 loops=1)
   ->  Hash  (cost=51448.60..51448.60 rows=1078660 width=23) (actual
time=2113.922..2113.922 rows=35 loops=1)
 ->  Seq Scan on movimento  (cost=0.00..51448.60 rows=1078660
width=23) (actual time=0.005..1919.003 rows=1077450 loops=1)
 Total runtime: 2114.367 ms
(6 rows)

A questão é: porque o índice não está sendo usado?



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramenta para programação

[Alexsander Rosa]

Em 17 de julho de 2014 17:22, Guimarães Faria Corcete DUTRA, Leandro 
l...@dutras.org escreveu:


 Já vi que é hora de parar esta discussão nunca vista aqui…


http://www.slate.com/articles/technology/bitwise/2014/05/oldest_software_rivalry_emacs_and_vi_two_text_editors_used_by_programmers.html


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramenta para programação

[Alexsander Rosa]

Em 17 de julho de 2014 12:20, Guimarães Faria Corcete DUTRA, Leandro 
l...@dutras.org escreveu:

 2014-07-17 9:21 GMT-03:00 Matheus Saraiva matheus.sara...@gmail.com:
  Que Ferramenta/IDE/Editor usar para programar para postgre? Estou
  criando uma funções com o pgModeler, mas não estou muito satisfeito.

 Gosto do GNU Emacs com o modo SQL.


Nah, vi é melhor. :-)

-- 
Atenciosamente,
Alexsander da Rosa
___
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 o Microsiga Protheus

[Alexsander Rosa]

Em 8 de julho de 2014 10:05, Roberto Mello roberto.me...@gmail.com
escreveu:


 Alguém tem uma sugestão de ERP para pequenas empresas que preste? Que
 suporte Linux e PostgreSQL?


www.rednaxel.com

-- 
Atenciosamente,
Alexsander da Rosa
___
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 o Microsiga Protheus

[Alexsander Rosa]

Em 8 de julho de 2014 10:53, Fabrízio de Royes Mello 
fabri...@timbira.com.br escreveu:

 On 08-07-2014 10:46, Alexsander Rosa wrote:
  Em 8 de julho de 2014 10:05, Roberto Mello roberto.me...@gmail.com
  escreveu:
 
 
  Alguém tem uma sugestão de ERP para pequenas empresas que preste? Que
  suporte Linux e PostgreSQL?
 
 
  www.rednaxel.com
 

 Conheço pessoalmente o Alexander (foi meu professor na graduação e
 amigo) e o trabalho/produto dele é excelente.

 Att,

 --
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento


Um screenshot recente:
http://port2laz.blogspot.com.br/2014/07/novo-screenshot-linux.html


Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] aplicativo para trabalhar com design de banco paralinux

[Alexsander Rosa]

PS: O SQL::Fairy continua com problemas nos COMMENT ON do PostgreSQL ?


Em 24 de agosto de 2013 18:29, Tiago Adami adam...@gmail.com escreveu:

 Em 24 de agosto de 2013 15:40, Leandro Guimarães Faria Corce DUTRA
 l...@dutras.org escreveu:
  Le 2013-A-24  14h26, Alexsander Rosa a écrit :
 
  (corte)
 
  Obrigado por traduzir num parágrafo exatamente o que eu penso.
 
  A voz da experiência!  Quando a gente é novo, quer tudo gráfico… depois,
 vê
  que o bom e velho código fonte é o que há.

 +1

 ---
 TIAGO J. ADAMI
 http://www.adamiworks.com
 @tiadami
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Compatibilidade entre versões

[Alexsander Rosa]

Tenho clientes usando a 10.04 LTS e a 12.04 LTS.
A primeira vem com o PG 8.4 e a segunda com o PG 9.1.
Não sei qual PG virá com a 14.04 LTS, que sai em abril.


Em 13 de fevereiro de 2014 10:33, Matheus de Oliveira 
matioli.math...@gmail.com escreveu:


 2014-02-13 10:16 GMT-02:00 Paulo Bastos prbalme...@bol.com.br:

 Senhores,

 alguem poderia, por favor, me informar onde encontro
 um guia de compatibilidade entre o UBUNTU e PostgresSQL.
 Por exemplo:

 No Ubuntu 10.04 consigo executar com tranquilidade o postgresql 9.2?
 A partir de que versão do postgresql devo atualizar minha versão do
 UBUNTU, por que?
 Uma tabelinha seria bem vinda



 É bem simples na verdade, você pode usar qualquer combinação de versões do
 PostgreSQL e do Ubuntu possíveis, mas cada um deles tem restrições
 (completamente independentes, apesar de similares):

 - No Ubuntu, utilize sempre o Ubuntu Server e uma versão LTS (Long Term
 Support), atualize sua versão para uma LTS mais nova sempre que possível e
 obrigatoriamente após 5 anos, veja mais detalhes em [1]. NUNCA! NUNCA!
 Nunca use uma versão que não seja LTS.

 - No PostgreSQL, utilize qualquer uma das últimas 5 versões (é lançada uma
 nova a cada ano), mas sempre (SEMPRE!) atualize para o último release. As
 versões do PostgreSQL são no formato X.Y.Z, você pode usar qualquer X.Y =
 5 anos atrás, mas o Z tem sempre que ser o maior possível. Por exemplo, a
 versão 8.4 é a mais antiga ainda suportada (não a use, vai perder o suporte
 no segundo semestre desse ano [2014]), mas já está no release 19, logo se
 fosse usá-la deveria usar a 8.4.19. Veja mais detalhes em [2]. Hoje
 recomendo usar a versão 9.3.

 Agora, tem mais algumas considerações, por exemplo, apesar de ambos dar
 suporte de 5 anos, você não deveria esperar tanto para atualizar. Tem
 também os pacotes do SO que devem ser atualizados periodicamente (apt-get
 update  apt-get upgrade).

 Mais um ponto a considerar, os repositórios padrões do Debian e Ubuntu são
 um tanto quanto desatualizados com relação às versões mais recentes do
 PostgreSQL, então talvez (e é recomendado) você queira usar o repositório
 oficial do PGDG (PostgreSQL Global Development Group), veja em [3].

 [1] https://wiki.ubuntu.com/LTS
 [2] http://www.postgresql.org/support/versioning/
 [3] http://wiki.postgresql.org/wiki/Apt

 Atenciosamente,
 --
 Matheus de Oliveira
 Analista de Banco de Dados
 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




-- 
Atenciosamente,
Alexsander da Rosa
___
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: Postgre embarcado? é Possivel?

[Alexsander Rosa]

Em 30 de janeiro de 2014 09:39, Rodrigo rodrigo.ina...@alcafoods.comescreveu:

 Então! Se eu resolvesse vender o sistema na caixa e o cliente mesmo
 instalar
  se possível queria que o cara clicasse em instalar e não perguntasse
 nada das opções do postgres pra ele...

 Rodrigo


Não seria melhor colocar o PG como pré-requisito (como o Windows, por
exemplo) e deixar por conta dele instalar o PostgreSQL? O seu instalador
poderia pedir o IP do servidor + senha do usuário postgres, conectar,
verificar os parâmetros (e abortar se for o caso), criar usuários, BD,
estrutura, etc.

-- 
Atenciosamente,
Alexsander da Rosa
___
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

[Alexsander Rosa]

Replicação Multi-Master?


Em 2 de dezembro de 2013 17:40, Daviramos Roussenq Fortunato 
daviramo...@gmail.com escreveu:

 Sim a ideia é essa.


 Em 2 de dezembro de 2013 16:29, Guimarães Faria Corcete DUTRA, Leandro 
 l...@dutras.org escreveu:

 2013/12/2 Daviramos Roussenq Fortunato daviramo...@gmail.com:
 
 Gostaria de instalar o Banco na Filiais que serviria para executar as
  consultas, e os Inserts fossem enviados para o Banco da Matriz, e o
 Banco da
  Matriz se atualizaria as filiais.
 
  Não posso fazer isso na APLICAÇÃO, eu preciso que o próprio SGDB
 consiga
  tratar. Alguém teria uma dica?

 Não me parece viável.  O SGBD teria de identificar que transações são
 somente consulta e que transações teriam alterações para saber onde
 fazer.

 Ou entendi o problema errado?
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




 --
 Atenciosamente
 Daviramos Roussenq Fortunato

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Vaga Analista de Suporte DBA - Fortaleza-CE

[Alexsander Rosa]

O problema é que muitas empresas trabalham com terceirização, e por isso
não dão a mínima. Enquanto houver clientes dispostos a pagar X por um
terceirizado sem se preocupar se ele vai ganhar X/2, X/3 ou X/4, essa
situação vai continuar. Se o funcionário (que geralmente nem tem carteira
assinada) achar ruim e sair, basta recorrer ao banco de currículos e
substituir. Quem perde é o cliente, quem sofre com a evasão de cérebros é
o cliente, não a empresa que presta o serviço de colocar gente lá dentro.


Em 1 de setembro de 2013 02:43, Miguel Bezerra
miguelbeze...@gmail.comescreveu:

 Concordo com o DUTRA. As empresas precisam aprender que o maior patrimônio
 delas são os funcionários.

 A empresa tem que pagar bem (lógico que este não é o único fator) para
 tentar manter os melhores profissionais com ela e como conseqüência poder
 exigir bastante destes.

 Pagar mal, não valorizar o funcionário, tirar vantagem do mais fraco ==
 evasão de cérebros...

 Se a empresa me paga mal e não me valoriza, ela já mostra como é sua
 política. Geralmente o funcionário não tem poder de mudar isso. Logo,
 penso: vou ficar mendigando aumento para que? Melhor procurar uma empresa
 melhor.


 Best regards,
 --
 Miguel Eugênio Ramalho Bezerra, M.Sc.
 Federal University of Pernambuco, Brazil
 home: http://www.cin.ufpe.br/~merb/
 twitter: @migueleugenio


 Em 26 de agosto de 2013 12:27, Roberto Mello 
 roberto.me...@gmail.comescreveu:



 On Saturday, August 24, 2013, Guimarães Faria Corcete DUTRA, Leandro
 wrote:

 2013/8/24 Roberto Mello roberto.me...@gmail.com:
  Houve vezes em que eu estava muito interessado em contratar o
 candidato,
  deposita entrevista, perguntava se ele tinha pretensão salarial, e -
 eu ja
  sabendo o meu teto - aguardava a resposta. Geralmente o candidato
 jogava uma
  pretensão baixa, com medo de me assustar. E [eu] fazia um joguinho,
 dizia que
  iria pensar, e no outro dia ligava para o candidato[…]

 Desculpa, Roberto, mas acho essa atitude não apenas injusta, mas uma
 visão de curto prazo, contraproducente.


 Se voce julgar o momento da contratação  como o fim da carreira do
 funcionário da empresa, sim, seria. Mas essa seria uma visao míope e
 incorreta. Obviamente era o oposto, o início. A partir daí seguiam-se bônus
 e Promocoes para os funcionários mais produtivos e dedicados, e para os que
 procuravam negociar aumentos de acordo com sua produtividade, como eu mesmo
 fiz em diversos momentos.

 Alguém que ganha menos do que deveria mais cedo ou mais tarde vai se


 Quem determina o que ele deveria ganhar em países nos quais
 o governo nao se mete forçando uma convenção coletiva de sindicatos de
 intenções duvidosas?

 Existe um valor de mercado, e é trabalho dos entes em negociação
 (trabalhador e empregador) informar-se dos valores de mercado, das suas
 necessidades e negociar os termos que desejarem.


 comparar com os colegas, e perceberá que foi injustiçado.  Procurará
 algo melhor, possivelmente noutro emprego, porque terá perdido
 confiança em seu atual empregador.  A rotatividade será ruim para a


 Injusticado? Por quem? Se ele conversar com os colegas e souber que
 ganha menos, poderá voltar para a mesa de negociação e aí negociar tendo
 agora a sua produção real (e não estimada) como ponto chave a seu favor. A
 empresa saberá também quanto o empregado vale para seus objetivos.


 empresa, a imagem dela sofrerá (mesmo que numa escala bem pequena,
 pelo menos entre amigos, família e colega do ludibriado), e a
 produtividade cairá não apenas pela rotatividade, mas até pela
 desmotivação enquanto o sujeito não sair.

 Se ele não soube negociar o salário para entrar, boa probabilidade de
 não saber negociar depois também e preferir sair em vez de enfrentar o
 temor de uma negociação com uma chefia que já o passou para trás uma
 vez.

 Mesmo que ele não perceba que foi enganado, ficará pelo menos com
 autoestima baixa, o que é ruim para a produtividade e o
 desenvolvimento do trabalho, e possivelmente achará a empresa mal
 gerida.  Mais desmotivação, portanto.


 Opa, enganado não, alto lá! Não atribua a mim o que não fiz. Eu
 perguntava a pretensão DA PESSOA. Era meu trabalho na empresa contratar a
 melhor pessoa dentro do que eu podia pagar. É o trabalho de todo
 pretendente negociar o salário.

 Eu nunca enganei ninguém na negociação, mas não era meu trabalho servir
 de consultor de carreira para pretendentes a emprego. Há ampla literatura
 disponível para quem quiser aprender e se ficasse comprovado que eu lesei a
 empresa oferecendo informações privilegiadas a um pretendente, então a
 empresa teria uma causa legal contra minha pessoa.


 Finalmente, alguém que ganha abaixo do que deveria tenderá a acreditar

 menos do que deveria em seu próprio desenvolvimento pessoal, e também
 terá menos recursos para investir em si mesmo.


 Dramático não? Parece que a pessoa morreu e nunca mais poderá decidir que
 aquele emprego não lhe serve (caso o empregador não queira renegociar) e
 procurar 

Re: [pgbr-geral] Problemas ao salvar caracter \ no banco com Zeos + Delphi 2007

[Alexsander Rosa]

Lembrando que \134 é octal para 92, que é o ASCII da contrabarra.


Em 31 de agosto de 2013 10:14, Euler Taveira eu...@timbira.com.brescreveu:

 On 30-08-2013 14:44, Rafael Naves wrote:
  Quando tento inserir o carácter \ o mesmo é substituído antes de ir ao
  banco por \134.
 
 Deixe-me adivinhar... ⩽ 9.0? Eu não utilizo Zeos, mas pode estar
 relacionado a nossa forma de escape padrão. Experimente definir
 'standard_conforming_strings = off' no postgresql.conf.

 Se não resolver, grave todos os comandos (log_statement = all) e nos
 apresente o comando INSERT (para dizermos se o problema é no Delphi/Zeos
 ou no Postgres).


 --
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




-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Vaga Analista de Suporte DBA - Fortaleza-CE

[Alexsander Rosa]

Há uns 10 anos atrás, em outra empresa, eu entrevistava candidatos a
desenvolvedor.
A gerente do RH combinou comigo: Se você gostar do candidato, pergunte a
pretensão salarial; se não aprovar, apenas encerre a entrevista e deixe
comigo.
A cada entrevista ela me dizia quanto a empresa tinha para a vaga. Por
exemplo, R$ 4500.
Se o candidato pedisse R$ 3000, ela dizia: Ok, está contratado.
Se ele pedisse R$ 5000, ela dizia: Isso é um pouco acima do que podemos
pagar e fazia uma contra-proposta, geralmente um pouco abaixo do teto,
digamos R$ 4000.
Mas isso era pra terceirização, onde às vezes num mesmo cliente tinha
programadores recebendo salários diferentes apenas porque negociaram melhor
ou pior.
Enfim, a minha dica é a mesma do Dutra: sempre peça um valor de topo.


Em 23 de agosto de 2013 11:19, Guimarães Faria Corcete DUTRA, Leandro 
l...@dutras.org escreveu:

 2013/8/23 Flávio Alves Granato flavio.gran...@gmail.com:
  2013/8/23 Vaga Analista de Suporte DBA - Fortaleza-CE 
 ticsele...@yahoo.com
  Salário a combinar + benefícios
  Favor enviar currículo com a pretensão salarial. Não informar a
 combinar.
 
  É a combinar ou não? Muito incoerênte.
  Me soa como: pegarei o menor valor que eu achar no mercado E negociarei
  para baixar mais ainda o preço.

 Por aí.

 Sem contar o endereço genérico.  Querem seus dados mas não identificam
 quem recruta?

 --
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] aplicativo para trabalhar com design de banco paralinux

[Alexsander Rosa]

Em 22 de agosto de 2013 14:33, Guimarães Faria Corcete DUTRA, Leandro 
l...@dutras.org escreveu:


 Lembrando também que os diagramas servem basicamente para comunicação
 com gerentes, clientes, novos desenvolvedores… para programadores
 experientes, DBAs, para o trabalho do dia‐a‐dia acabam sendo um peso
 morto.  E os diagramas gerados automaticamente são muito mais
 práticos, até porque os algoritmos usados tanto pelo AutoDoc quanto
 pelo SQL::Fairy são melhores que a mão e o olho humanos de longe.


Obrigado por traduzir num parágrafo exatamente o que eu penso.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Como descobrir o nome do ínidice/constraint que causou erro?

[Alexsander Rosa]

Estou colocando COMMENTS nas constraints com mensagens de erro mais claras.
Quero poder converter isto:
ERROR:  new row for relation produto violates check constraint
chk_produto_precomin
Nisto:
O preço de tabela do produto não pode estar abaixo do preço mínimo.

Gostaria de uma maneira de descobrir o SQLSTATE e o ID da constraint que
deu erro.
Em último caso vou procurar tudo que está entre aspas no catálogo.

-- 
Atenciosamente,
Alexsander da Rosa
___
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 descobrir o nome do ínidice/constraint que causou erro?

[Alexsander Rosa]

Em 24 de junho de 2013 11:09, Flavio Henrique Araque Gurgel 
fla...@4linux.com.br escreveu:

 Estou colocando COMMENTS nas constraints com mensagens de erro mais
 claras.
 Quero poder converter isto:
 ERROR:  new row for relation produto violates check constraint
 chk_produto_precomin
 Nisto:
 O preço de tabela do produto não pode estar abaixo do preço mínimo.


 Você pode tratar isso na sua aplicação através de tratamento de excessões.

 Além da dica do Juliano você pode fazer um gatilho (trigger) do tipo
 before e que lança um raise exception caso dê o erro.


Agradeço as sugestões, mas quero fazer algo no banco pra poder ser usado
por todas as aplicações.
E acho que colocar um trigger em cada tabela só pra isso me parece
exagerado (e trabalhoso).

-- 
Atenciosamente,
Alexsander da Rosa
___
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 descobrir o nome do ínidice/constraint que causou erro?

[Alexsander Rosa]

Em 24 de junho de 2013 11:09, Vinicius Santos 
vinicius.santos.li...@gmail.com escreveu:


 Estou colocando COMMENTS nas constraints com mensagens de erro mais claras.
 Quero poder converter isto:
 ERROR:  new row for relation produto violates check constraint
 chk_produto_precomin
 Nisto:
 O preço de tabela do produto não pode estar abaixo do preço mínimo.


 Você sabe o nome da constraint, basta pegar no catálogo o comentário da
 mesma.


Por você sabe o nome da constraint você quer dizer: você pode extrair o
nome da constraint por regex?
Neste caso eu preciso ainda descobrir se a string entre aspas é uma
constraint, um índice, uma tabela, etc.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Latin1 ou UTF-8

[Alexsander Rosa]

Em 3 de junho de 2013 12:49, Gerson gersoncjun...@gmail.com escreveu:

 Prezados boa tarde.

 Qual a diferença entre esses dois charset? O que eu ganho e perco com cada
 um? Obrigado a todos pelas respostas.

 Ats,
 Gerson Jr.
 gersoncjun...@gmail.com


UTF-8 sem a menor sombra de dúvida. LATIN1 é coisa do século passado.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Material para replicação de dados Multi-master

[Alexsander Rosa]

2013/5/16 Euler Taveira eu...@timbira.com.br

 On 16-05-2013 16:00, Alexsander Rosa wrote:
  Não achei esta mensagem do Euler que você respondeu...
 
 Vide o histórico [1] da lista.
 [1]
 http://listas.postgresql.org.br/pipermail/pgbr-geral/2013-May/034934.html


No meu Gmail caiu tudo como SPAM dizendo várias pessoas marcaram como
spam. Estranho, não?

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Material para replicação de dados Multi-master

[Alexsander Rosa]

Em 16 de maio de 2013 00:44, Euler Taveira eu...@timbira.com.br escreveu:

 On 15-05-2013 20:51, Fábio Thomaz wrote:
O cenário é básico: 1 matriz e 3 filiais precisando compartilhar
  informações, onde algumas destas informações (tabelas) serão únicas para
  todas as filiais, como um exemplo eu poderia dar o cadastro de produto.
 
 Não é.


Já pensei em algo assim, considerando N filiais e uma matriz:
- um DB global onde a matriz é master e as filiais são slave;
- N DB locais onde cada filial é master e a matriz é slave;
- cada filial teria apenas 2 databases, o global (ro) e seu local (rw)
- na matriz haveria N+1 databases, o global (rw) mais N locais (ro)
- uma aplicação rodando na matriz atualizando o Global lendo os DB locais;
- uma replicação Matriz - Filiais master/slave (nativa do PG, por exemplo);
- N replicações Filial - Matriz master/slave (nativa do PG, por exemplo);
- a solução de conflitos seria na aplicação que atualiza o BD global;
- as PK artificiais incluiriam o código N da filial quando necessário.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Material para replicação de dados Multi-master

[Alexsander Rosa]

Em 17 de maio de 2013 14:23, Euler Taveira eu...@timbira.com.br escreveu:

 On 17-05-2013 14:17, Alexsander Rosa wrote:
  Já pensei em algo assim, considerando N filiais e uma matriz:
  - um DB global onde a matriz é master e as filiais são slave;
  - N DB locais onde cada filial é master e a matriz é slave;
  - cada filial teria apenas 2 databases, o global (ro) e seu local (rw)
  - na matriz haveria N+1 databases, o global (rw) mais N locais (ro)
  - uma aplicação rodando na matriz atualizando o Global lendo os DB
 locais;
  - uma replicação Matriz - Filiais master/slave (nativa do PG, por
 exemplo);
  - N replicações Filial - Matriz master/slave (nativa do PG, por
 exemplo);
  - a solução de conflitos seria na aplicação que atualiza o BD global;
  - as PK artificiais incluiriam o código N da filial quando necessário.
 
 Talvez ao invés de bancos de dados você utilizasse esquemas. Replicação
 nativa não daria certo (ela replica toda instância); a não ser que você
 tenha mais de uma instância. Além disso, você não precisaria de
 replicação nas duas direções; apenas uma já seria suficiente.


Apenas numa direção, Matriz - Filiais? Ou apenas Filiais - Matriz? Como?

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Material para replicação de dados Multi-master

[Alexsander Rosa]

Em 15 de maio de 2013 20:51, Fábio Thomaz fabio_...@yahoo.com.br escreveu:

   Olá pessoal, sou iniciante no uso do PostgreSQL, entrei na lista
 recentemente e venho em busca de maiores informações para que eu possa
 criar um modelo que atenda um cliente.

   O cenário é básico: 1 matriz e 3 filiais precisando compartilhar
 informações, onde algumas destas informações (tabelas) serão únicas para
 todas as filiais, como um exemplo eu poderia dar o cadastro de produto.

   Pensei em criar uma aplicação que acessasse o servidor na nuvem, mas não
 posso correr o risco de deixar a empresa sem sistema por uma eventual falha
 na rede externa.

   Então teríamos 5 SGDB's: Nuvem (Principal), Matriz, Filial-1, Filial-2 ,
 Filial-3.


   Bem, com estas informações acima, os nobres colegas do grupo poderiam me
 ajudar, direcionando-me a fontes de pesquisa onde eu possa implementar este
 cenário?

 Desde já agradeço

 Att,
 Fábio Thomaz


Olhou o Bucardo?


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Material para replicação de dados Multi-master

[Alexsander Rosa]

Em 16 de maio de 2013 13:15, Fábio Thomaz fabio_...@yahoo.com.br escreveu:

 Olá Euler,

   Quando você diz: Fuja disso! Tecnicamente frágil., seria pela possível
 falha na geração deste número sequencial negativo?

   Pois para estas tabelas pensei em ter uma sequencia normal, mas sendo
 chamada através de um Trigger que iria capturar o próximo valor,
 multiplicar por -1 e atribuir ao campo. Neste caso eu também terei que
 padronizar algumas coisas, tipo, se o ID vier nulo do meu comento SQL de
 inclusão, o banco pega o valor da sequencia e pronto, se vier com o valor
 0 por exemplo, o Trigger testa o valor e gera um valor negativo.

   Há, e neste caso eu teria duas sequencias para a mesma tabela, uma
 sequencia normal e outra apenas para esta ocasião dos negativos, lembrando
 que seria apenas em algumas tabelas usadas em recursos que o sistema não
 irá poder parar, o restante eu informo que a operação está indisponível por
 problemas de comunicação com o servidor e pronto.

 Att,
 Fábio Thomaz


Não achei esta mensagem do Euler que você respondeu...


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Parametros para uma PL

[Alexsander Rosa]

Depende do caso. Se forem, por exemplo, até 15 números inteiros, pode-se
usar um array.
Outra alternativa  é usar um parâmetro text, separar por vírgula e depois
fazer um string_to_array.
Se forem sempre 15 parâmetros, cada um de um tipo diferente, é melhor
tipificar e nomear cada um deles.

Em 10 de abril de 2013 14:26, Joel Landim Mourão jlmou...@gmail.comescreveu:

 Boa tarde colegas,

 Bom minha duvida, tenho uma necessidade de passar 15 parametros para uma
 PL, existe alguma recomendação, ou sugestão para o caso.

 Terei casos usando versão 9.2 e 8.2 (sendo atualizados gradualmente)

 Obrigado a todos

 --
 Joel Landim Mourão




-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Migração do Postgres 8.2 para 9.2 - Problemas com Casts e Operadores

[Alexsander Rosa]

Em 8 de abril de 2013 12:02, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:


 O cenário *ideal* é vc corrigir sua aplicação ajustando esse problema dos
 casts implicitos, mas como isso pode levar muito tempo, então usamos essa
 abordagem e funcionou adequadamente, e realizamos esse processo em 10meses.


Aqui temos um produto que tem que rodar em qualquer versão de 8.3 pra cima
-- inclusive é comum o cliente ter vários servidores replicando com versões
diferentes. Não dá pra impor um upgrade ao cliente, geralmente ele faz isso
no seu ritmo, de acordo com algum calendário da Gerência de TI. Muitas
vezes o upgrade é do servidor inteiro, com troca de equipamento.

Isso nos fez desenvolver um procedimento de ir testando a aplicação nas
novas versões de PostgreSQL à medida em que vão saindo. Assim, quando algum
cliente resolve atualizar o PostgreSQL, o processo é transparente. Tivemos
que arrumar os problemas dos casts lá atrás, quando saiu a 8.3; depois
tivemos o problema dos escapes nas strings (ex: '\n' vira E'\n') e assim
por diante.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] pgModeler

[Alexsander Rosa]

Ubuntu 64 (+1)

Em 2 de abril de 2013 09:52, Bruno Silva bemanuel...@gmail.com escreveu:

 Aqui rodou sem problemas. Ubuntu 64 bits.

 Bruno E. A. Silva.



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Voltando ao assunto, mas com outra visão (CHAR ou VARCHAR) ?

[Alexsander Rosa]

Sim CFOP é um identificador único, definido em Lei e usado por inúmeros
documentos fiscais (NFe, SPED, etc).
Logo abaixo da DDL eu passei o link onde achei aquilo, parece ser um modelo
de verdade.
Não seria necessário ter um ID, a PK poderia ser o próprio CFOP. O mesmo
vale para CST, NCM, etc.

Em 3 de abril de 2013 15:54, Marcelo da Silva marc...@ig.com.br escreveu:

 Vai ver que depois o cara coloca Unique porque ele tem que ser um
 identificador mas não necessariamente sequencial
 Vai saber


 2013/4/3 Leonardo Cezar lhce...@gmail.com

 2013/4/3 Alexsander Rosa alexsander.r...@gmail.com

 Que tal isso aqui?:

 CREATE TABLE CFOP (ID INTEGER NOT NULL,CFOP   INTEGER,
 DESCRICAO  BLOB SUB_TYPE 1 SEGMENT SIZE 80,
 APLICACAO  BLOB SUB_TYPE 1 SEGMENT SIZE 80
 );


 Agora já não sei se brincas ou se falas sério...

 CFOP não é um identificador único?

 -Leo



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Voltando ao assunto, mas com outra visão (CHAR ou VARCHAR) ?

[Alexsander Rosa]

Em 2 de abril de 2013 10:23, Marcelo da Silva marc...@ig.com.br escreveu:


 
  Tip: There are no performance differences between these three types,
 apart from increased storage size when using the blank-padded type, and a
 few extra cycles to check the length when storing into a length-constrained
 column. While character(n) has performance advantages in some other
 database systems, it has no such advantages inPostgreSQL. In most
 situations text or character varying should be used instead.
 
  http://www.postgresql.org/docs/9.2/static/datatype-character.html
 
  Entendo que a diferença seria apenas de espaço em disco mesmo. Use
 varchar e boa.


Strings de até 126 bytes têm 1 byte de overhead (para o tamanho da String);
strings maiores têm 4 bytes de overhead.
Não seria um ganho de velocidade se o PostgreSQL armazenasse strings de 2,
4 e 8 bytes em tipos unsigned?
Sei que existe o tipo char (com aspas) que fica armazenado em exatamente
1 byte.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Voltando ao assunto, mas com outra visão (CHAR ou VARCHAR) ?

[Alexsander Rosa]

Em 2 de abril de 2013 12:01, Leonardo Cezar lhce...@gmail.com escreveu:

 On Tue, Apr 2, 2013 at 10:36 AM, Alexsander Rosa 
 alexsander.r...@gmail.com wrote:

  Entendo que a diferença seria apenas de espaço em disco mesmo. Use
 varchar e boa.

 Strings de até 126 bytes têm 1 byte de overhead (para o tamanho da
 String); strings maiores têm 4 bytes de overhead.
 Não seria um ganho de velocidade se o PostgreSQL armazenasse strings de
 2, 4 e 8 bytes em tipos unsigned?
 Sei que existe o tipo char (com aspas) que fica armazenado em
 exatamente 1 byte.


 Hmm... não é assim que funciona.

 Todos os tipos de tamanho variável (inclua aí o char e deixe o toast fora
 disso – já explico) compartilham uma mesma estrutura chamada varlena. Este
 é o cabeçalho padrão para bytea, bpchar (vulgo char), cstrings, ca e
 possui a seguinte definição:

 estrutura Varlena
   v_len[4] -- informações sobre o tamanho do dado armazenado;
   v_dat[1] -- Início do array de armazenamento;

 Este tipo de estrutura é muito utilizado como um /pattern/ e basicamente
 possibilita a extensibilidade de tipos, funcionalidade que seria inviável
 com tipos unsigned – se não me engano v_len já foi inteiro num belo dia.
 Tentei fazer o diff com tags antigos no git mas me perdi :-\

 Quando vc cria um tipo de dados com restrição de comprimento, vc habilita
 no catálogo o armazenamento com atttypmod (  0 – ver
 pg_attribute.atttypmod). Este mesmo atributo é utilizado para operações de
 validações com a constante VLHDRSIZE (depois confirmo este nome) que é o
 tamanho do header da estrutura varlena.

 Esta arquitetura é histórica e existe desde dos primórdios do elefante e a
 mudança certamente exigiria uma refatoração inclusive conceitual da coisa
 toda.

 O char com aspas pra mim é novidade

 Abraço!

 -Leo


Na verdade a minha viagem foi pensando assim: imagine que você tem um
tipo de operação com 5 letras A-Z (ex: VENDA, COMPR, DEVOL, etc) usado
como FK em vários lugares. Eu fiquei pensando: considerando que isso vai
ter uns 10 bytes no Varlena, não seria mais rápido se sua aplicação
convertesse isso para um número de 4 bytes (ex: VENDA = 21x26⁴ 4x26³ 13x26²
+ 3x26 + 0 = 9596496 + 70304 + 8788 + 78 + 0 = 9675666) e usasse este
número como FK ao invés de um text? A codificação/decodificação seria em
nível de aplicação/apresentação.

Eu nunca usei isso, mas fiquei pensando vendo este overhead do Varlena, que
pode ser um exagero em strings pequenas.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Voltando ao assunto, mas com outra visão (CHAR ou VARCHAR) ?

[Alexsander Rosa]

Em 2 de abril de 2013 13:08, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:


 2013/4/2 Alexsander Rosa alexsander.r...@gmail.com


 Na verdade a minha viagem foi pensando assim: imagine que você tem um
 tipo de operação com 5 letras A-Z (ex: VENDA, COMPR, DEVOL, etc) usado
 como FK em vários lugares. Eu fiquei pensando: considerando que isso vai
 ter uns 10 bytes no Varlena, não seria mais rápido se sua aplicação
 convertesse isso para um número de 4 bytes (ex: VENDA = 21x26⁴ 4x26³ 13x26²
 + 3x26 + 0 = 9596496 + 70304 + 8788 + 78 + 0 = 9675666) e usasse este
 número como FK ao invés de um text? A codificação/decodificação seria em
 nível de aplicação/apresentação.

 Eu nunca usei isso, mas fiquei pensando vendo este overhead do Varlena,
 que pode ser um exagero em strings pequenas.


 Não é tão simples como parece... nessa sua abordagem vc nem está
 considerando outros encodings... imagina uma pequena string com caracteres
 chineses... ;-)

 Att,


No meu exemplo eram caracteres de A-Z codificados como 0-25.



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Relacionamento Ternário com Foreign Key?

[Alexsander Rosa]

Em 12 de dezembro de 2012 20:56, Renato Augusto renato@gmail.com escreveu:
 Boa noite

 Tenho uma estrutura semelhante as tabelas abaixo:


Cadê o Leandro? :-)


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ignorar maiúsculas no nome das tabelas

[Alexsander Rosa]

Outra que pode ou não ser viável: dar um DUMP modo texto e converter
(ou tirar as aspas).

Em 13 de dezembro de 2012 16:38, Matheus de Oliveira
matioli.math...@gmail.com escreveu:
 2012/12/13 Euler Taveira eu...@timbira.com

 On 13-12-2012 11:17, Flávio Alves Granato wrote:
  Teria como eu desabilitar alguma opção no postgres que o faça a não
  levar em consideração se o nome das tabelas e colunas estão em
  maiúsculas ou não?
 
 Não.


 Uma solução que vejo é realizar uma operação para renomear tudo, mas aí pode
 quebrar a aplicação.

 Outra solução (tosquissima) seria criar Views para mascarar as tabelas
 como nomes mais simples, uma espécie de proxy.



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] top-posting e regras da lista

[Alexsander Rosa]

Em 11 de dezembro de 2012 18:19, Euler Taveira eu...@timbira.com escreveu:

 On 11-12-2012 16:37, Alexsander Rosa wrote:
  Texto puro é simples, acabo de clicar e converter este email.
 
 É *exatamente* esta opção que os usuários do Gmail devem utilizar.


Mas e o bottom-post? Isso não tem no Gmail.

--
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] top-posting e regras da lista

[Alexsander Rosa]

Em 12 de dezembro de 2012 11:45, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:

 Em 12-12-2012 11:38, Alexsander Rosa escreveu:
 Mas e o bottom-post? Isso não tem no Gmail.

 O que a lista pede não é bottom-post.
 A lista pede pra responder quotando.


Estou me referindo à seguinte frase dita nesta thread:
O Gmail é configurável, inclusive permitindo texto puro e bottom-post
por padrão, com assinatura no final.

Gostaria de aprender a configurar o bottom-post por padrão no Gmail.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] top-posting e regras da lista

[Alexsander Rosa]

Em 12 de dezembro de 2012 12:04, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
 Em 12-12-2012 12:03, Flavio Henrique Araque Gurgel escreveu:
 http://userscripts.org/scripts/show/35866
 É uma extensão para Firefox. Não é uma funcionalidade intrínseca do
 Gmail nem dos labs.

 Ooops, endereço errado. Esse é do projeto antigo. Para Firefox novo use
 este:
 https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/


Não uso Firefox, uso Chromium, mas obrigado mesmo assim. Sigo fazendo
manualmente.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Limites do PostgreSQL

[Alexsander Rosa]

Dei uma olhada rápida aqui, um cliente tem uma tabela que aumenta 10
milhões de registros por mês.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Limites do PostgreSQL

[Alexsander Rosa]

Sim, não estamos competindo, estamos tranqüilizando o Eduardo, acho que
quanto mais exemplos ele tiver, melhor.

Em 11 de dezembro de 2012 11:51, Flavio Henrique Araque Gurgel 
fla...@4linux.com.br escreveu:


 Alexsander Rosa alexsander.r...@gmail.com escreveu:

 Dei uma olhada rápida aqui, um cliente tem uma tabela que aumenta 10
 milhões de registros por mês.

 Tenho cliente que faz 10 milhões por dia.
 Não é competição aqui.  Mas essa questão de limites é o que foi
 apresentado a partir da documentação.


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] top-posting e regras da lista

[Alexsander Rosa]

Em 6 de dezembro de 2012 13:08, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:


 Usei o Gmail por muito tempo pra responder aqui na lista.
 O Gmail é configurável, inclusive permitindo texto puro e bottom-post
 por padrão, com assinatura no final. Aí, quotar a resposta era muito fácil.


Acho que não existe esta opção de bottom-post no Gmail. Há scripts via
GreaseMonkey (uma extensão), mas não são práticos pra quem usa mais de
um PC ou mais de um navegador. Texto puro é simples, acabo de clicar e
converter este email. Assinatura também. Mas bottom-post, desculpe, se
existe (sem necessidade de instalar coisas no navegador) por favor
explique como configurar.

--
Atenciosamente,
Alexsander da Rosa
___
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: Listar triggers das Tabelas.

[Alexsander Rosa]

Nesta solução cada trigger aparece N vezes, uma pra cada combinação
condição/evento; a anterior era mais limpa.
Como meu objetivo é apenas comparar bancos de dados, mostrar tudo numa
linha só gera menos linhas no diff.
Acabei colocando na minha view de comparação a primeira solução, apesar de
não ser tão elegante.


Em 14 de novembro de 2012 12:04, JotaComm jota.c...@gmail.com escreveu:

 Pessoal,

 Em 13 de novembro de 2012 10:53, Matheus de Oliveira 
 matioli.math...@gmail.com escreveu:



 2012/11/13 Paulo pa...@visualpsistemas.com.br

 Ola Pessoal,

 ** **

 Preciso saber quais tabelas e quais triggers cada uma delas possui.

 Alguém conhece o comando para esta consulta ¿

 **


 O ideal seria usar o information_schema, mas pelo catálogo seria isso:

 SELECT r.relname AS tblname, t.tgname,
 pg_catalog.pg_get_triggerdef(t.oid, true) AS tgdef, t.tgenabled
 FROM pg_catalog.pg_class r INNER JOIN pg_catalog.pg_trigger t ON r.oid =
 t.tgrelid
 WHERE r.relkind = 'r' AND NOT t.tgisinternal
 ORDER BY 1, 2;


 Segue uma solução através do information_schema:

 SELECT triggers.trigger_schema,

 triggers.trigger_name,

 triggers.condition_timing,

 triggers.event_manipulation,

 tables.table_schema,

 tables.table_name,

 triggers.action_orientation,

 triggers.action_statement

 FROM information_schema.tables JOIN information_schema.triggers

 ON tables.table_name=triggers.event_object_table;


 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



 Abraços
 --
 JotaComm
 http://jotacomm.wordpress.com

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
___
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: REF: Listar triggers das Tabelas - RESOLVIDO.

[Alexsander Rosa]

E abaixo da versão 9, tem alguma forma?


Em 13 de novembro de 2012 11:24, Paulo pa...@visualpsistemas.com.brescreveu:

 Obrigado pessoal a todas as respostas, problema resolvido.

 ** **

 Abraços.

 ** **

 * Paulo.*

 [image: vp_logo]

 pa...@visualpsistemas.com.br**

 48 - 3657.1963

 48 - 9906-9136

 ** **

 ** **

 *De:* pgbr-geral-boun...@listas.postgresql.org.br [mailto:
 pgbr-geral-boun...@listas.postgresql.org.br] *Em nome de *Matheus de
 Oliveira
 *Enviada em:* terça-feira, 13 de novembro de 2012 10:53
 *Para:* Comunidade PostgreSQL Brasileira
 *Assunto:* Re: [pgbr-geral] REF: Listar triggers das Tabelas.

 ** **

 ** **

 2012/11/13 Paulo pa...@visualpsistemas.com.br

 Ola Pessoal,

  

 Preciso saber quais tabelas e quais triggers cada uma delas possui.

 Alguém conhece o comando para esta consulta ¿

  


 O ideal seria usar o information_schema, mas pelo catálogo seria isso:

 SELECT r.relname AS tblname, t.tgname, pg_catalog.pg_get_triggerdef(t.oid,
 true) AS tgdef, t.tgenabled
 FROM pg_catalog.pg_class r INNER JOIN pg_catalog.pg_trigger t ON r.oid =
 t.tgrelid
 WHERE r.relkind = 'r' AND NOT t.tgisinternal
 ORDER BY 1, 2;

 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




-- 
Atenciosamente,
Alexsander da Rosa
image003.jpg___
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: REF: Listar triggers das Tabelas - RESOLVIDO.

[Alexsander Rosa]

Num PG8:
ERROR:  function pg_catalog.pg_get_triggerdef(oid, boolean) does not exist
LINHA 1: SELECT r.relname AS tblname, t.tgname, pg_catalog.pg_get_tri...
^
DICA:  No function matches the given name and argument types. You might
need to add explicit type casts.



Em 13 de novembro de 2012 12:37, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:


 Em 13 de novembro de 2012 12:34, Alexsander Rosa 
 alexsander.r...@gmail.com escreveu:

 E abaixo da versão 9, tem alguma forma?


 Alexsander,

 O Matheus respondeu essa pergunta:


 http://listas.postgresql.org.br/pipermail/pgbr-geral/2012-November/033438.html

 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




-- 
Atenciosamente,
Alexsander da Rosa
___
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: REF: Listar triggers das Tabelas - RESOLVIDO.

[Alexsander Rosa]

ERRO:  coluna t.tgisinternal não existe
LINE 3: WHERE r.relkind = 'r' AND NOT t.tgisinternal



2012/11/13 Matheus de Oliveira matioli.math...@gmail.com



 On Tue, Nov 13, 2012 at 1:21 PM, Alexsander Rosa 
 alexsander.r...@gmail.com wrote:

 Num PG8:
 ERROR:  function pg_catalog.pg_get_triggerdef(oid, boolean) does not exist
 LINHA 1: SELECT r.relname AS tblname, t.tgname, pg_catalog.pg_get_tri...
 ^
 DICA:  No function matches the given name and argument types. You might
 need to add explicit type casts.



 Simples, é só tirar o segundo parâmetro na chamada da função:

 SELECT r.relname AS tblname, t.tgname, pg_catalog.pg_get_triggerdef(t.oid)
 AS tgdef, t.tgenabled

 FROM pg_catalog.pg_class r INNER JOIN pg_catalog.pg_trigger t ON r.oid =
 t.tgrelid
 WHERE r.relkind = 'r' AND NOT t.tgisinternal
 ORDER BY 1, 2;



 Em 13 de novembro de 2012 12:37, Fabrízio de Royes Mello 
 fabriziome...@gmail.com escreveu:


 Em 13 de novembro de 2012 12:34, Alexsander Rosa 
 alexsander.r...@gmail.com escreveu:

 E abaixo da versão 9, tem alguma forma?


 Alexsander,

 O Matheus respondeu essa pergunta:


 http://listas.postgresql.org.br/pipermail/pgbr-geral/2012-November/033438.html

 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




 --
 Atenciosamente,
 Alexsander da Rosa



 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




 --

 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




-- 
Atenciosamente,
Alexsander da Rosa
___
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: REF: Listar triggers das Tabelas - RESOLVIDO.

[Alexsander Rosa]

Fiz assim pra funcionar nos dois (PG 8.x e 9.x):
SELECT r.relname AS tblname, t.tgname, pg_catalog.pg_get_triggerdef(t.oid)
AS tgdef, t.tgenabled FROM pg_catalog.pg_class r INNER JOIN
pg_catalog.pg_trigger t ON r.oid = t.tgrelid WHERE r.relkind = 'r' AND
t.tgname not like 'RI_%' AND r.relname not like 'pg_%' ORDER BY 1, 2;



2012/11/13 Alexsander Rosa alexsander.r...@gmail.com

 ERRO:  coluna t.tgisinternal não existe
 LINE 3: WHERE r.relkind = 'r' AND NOT t.tgisinternal



 2012/11/13 Matheus de Oliveira matioli.math...@gmail.com



 On Tue, Nov 13, 2012 at 1:21 PM, Alexsander Rosa 
 alexsander.r...@gmail.com wrote:

 Num PG8:
 ERROR:  function pg_catalog.pg_get_triggerdef(oid, boolean) does not
 exist
 LINHA 1: SELECT r.relname AS tblname, t.tgname, pg_catalog.pg_get_tri...
 ^
 DICA:  No function matches the given name and argument types. You might
 need to add explicit type casts.



 Simples, é só tirar o segundo parâmetro na chamada da função:

 SELECT r.relname AS tblname, t.tgname,
 pg_catalog.pg_get_triggerdef(t.oid) AS tgdef, t.tgenabled

 FROM pg_catalog.pg_class r INNER JOIN pg_catalog.pg_trigger t ON r.oid =
 t.tgrelid
 WHERE r.relkind = 'r' AND NOT t.tgisinternal
 ORDER BY 1, 2;



 Em 13 de novembro de 2012 12:37, Fabrízio de Royes Mello 
 fabriziome...@gmail.com escreveu:


 Em 13 de novembro de 2012 12:34, Alexsander Rosa 
 alexsander.r...@gmail.com escreveu:

 E abaixo da versão 9, tem alguma forma?


 Alexsander,

 O Matheus respondeu essa pergunta:


 http://listas.postgresql.org.br/pipermail/pgbr-geral/2012-November/033438.html

 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




 --
 Atenciosamente,
 Alexsander da Rosa



 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




 --

 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




 --
 Atenciosamente,
 Alexsander da Rosa





-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Mesmo CHECK fica diferente na pg_constraint (PG 8 vs PG 9)

[Alexsander Rosa]

PG 8.x:
chk_descricao CHECK (NOT desc_produto::text ~ '[*;\\x05C\\n\\r\\t]'::text)

PG 9.x:
chk_descricao CHECK (NOT desc_produto::text ~ '[*;\x05C\n\r\t]'::text)

Isso aparece como diferente na minha ferramenta de comparação:
SELECT consrc FROM pg_constraint WHERE conname = 'chk_descricao';

Alguma sugestão?

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Mesmo CHECK fica diferente na pg_constraint (PG 8 vs PG 9)

[Alexsander Rosa]

Somente no 9.1 o default ficou sendo ON.


2012/11/12 Fabrízio de Royes Mello fabriziome...@gmail.com


 Em 12 de novembro de 2012 17:43, Alexsander Rosa 
 alexsander.r...@gmail.com escreveu:

 O ideal então é ligar o standard_conforming_strings no PG8, não?


 Sim, esse comportamento foi introduzido na 8.2 [1]. Veja a nota abaixo:

 Enable 
 standard_conforming_stringshttp://www.postgresql.org/docs/8.2/static/runtime-config-compatible.html#GUC-STANDARD-CONFORMING-STRINGS
  to
 be turned on (Kevin Grittner)

 This allows backslash escaping in strings to be disabled, making
 PostgreSQL more standards-compliant. The default is off for backwards
 compatibility, but future releases will default this to on.
 Vc terá que ter alguns cuidados ao escrever SQL com escapes utilizando o
 'E' no inicio da string, para dizer ao banco que a mesma contém escapes,
 tipo:

 postgres=# SHOW standard_conforming_strings ;
  standard_conforming_strings
 -
  on
 (1 row)

 postgres=# SELECT 'Marca D\'Água';
 postgres'# ';
 ERROR:  syntax error at or near ';
 '
 LINE 1: select 'Marca D\'Água';
  ^
 postgres=#
 postgres=#
 postgres=# SELECT E'Marca D\'Água';
?column?
 --
  Marca D'Água
 (1 row)


 Com ele desligado sempre irá considerar o escape:

 postgres=# set standard_conforming_strings to off;
 SET
 postgres=# select 'Marca D\'Água';
?column?
 --
  Marca D'Água
 (1 row)


 Att,

 [1] http://www.postgresql.org/docs/8.2/static/release-8-2.html#AEN80530

 --
 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




-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Migração de base Postgres para Oracle

[Alexsander Rosa]

Em 26 de outubro de 2012 11:03, Leonardo Cezar lhce...@gmail.com escreveu:

 (...) Não existe legado Oracle que vai perdurar por algum tempo,
 esses sistemas continuarão a coexistir com sistemas livres e o motivo
 eu não arrisco a dizer, mas acho que a maioria já sabe.


Propina? Fui funcionário público também (Exército), aliás fui presidente de
comissão de licitação. Infelizmente o sistema está podre, na época fui
repreendido por querer incluir outras empresas nas cartas convites (de fora
do esquema). E pior, se você comprar mais barato também toma mijada
porque ano que vem a verba será menor. Não tem como não haver desperdício
com o sistema atual.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Listar Bancos de Dados

[Alexsander Rosa]

psql -l

Em 16 de outubro de 2012 13:59, Ronei Heck ro...@rhsistemas.com.brescreveu:

   Senhores,

 Tem como listar os bancos de dados de um servidor?

 Muito obrigado.

 Ronei Heck
 Postgres 9.1
 Clarion 6.1
 Windows 7


 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Substituição dos ORM

[Alexsander Rosa]

Em 12 de setembro de 2012 17:16, Guimarães Faria Corcete DUTRA, Leandro 
l...@dutras.org escreveu:

 2012/9/12 Bruno Silva bemanuel...@gmail.com:
  Éguas Dutra, eu nunca cheguei a trabalhar diretamente, mas depois de
  ver o cara usar a calculadora pra definir o tamanho do arquivo a ser
  alocado, vi que a coisa era complicada!

 Nada, era a própria simplicidade… cheio de limitações e ineficiências,
 mas para os casos gerais, como era o sistema de contas correntes do
 Itaú, atendia às maravilhas e era extremamente transparente e fácil de
 depurar.


E dava pra fazer pesquisa com grep no console mesmo... mas no geral eu via
mais desvantagens do que vantagens. O arquivo-texto por colunas é um
extremo, um XML cheio de overhead é outro extremo, acho que o ideal é usar
algo intermediário.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Substituição dos ORM

[Alexsander Rosa]

Em 11 de setembro de 2012 15:46, Guimarães Faria Corcete DUTRA, Leandro 
l...@dutras.org escreveu:


 Bem que dizem que Java é o novo Cobol.


JAVA IS THE NEW COBOL.
Sensacional.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Servidor de Banco de Dados

[Alexsander Rosa]

Nosso maior cliente é um varejista que tem 14 servidores, um em cada
loja/depósito, e TODOS são máquinas padrão desktop, os mais novos são i5
2500 com 16 GB mas tem loja com Core2 Duo com 4 Gb. A maioria dos
servidores tem 8 Gb de RAM, todos com Linux e PG de 8.3 a 9.1 (conforme a
distro). A base (replicada em todos) tem mais de 100 Gb, no total
geralmente são mais de 200 usuários simultâneos, e na média a carga não
chega a 1000 TPM (contando apenas IUD, sem contar triggers).

Em resumo: não sei se você precisa mesmo de um mega-servidor caríssimo.

Em 31 de agosto de 2012 15:58, Jean Domingues ejdom...@yahoo.com.brescreveu:

 Pessoal, sei que a lista não o lugar mais correto pra esta pergunta, mas
 vou arriscar. Vamos comprar um servidor para o banco de dados da empresa. É
 uma indústria, e o banco já está bem robusto (20 GB). Gostaria de algumas
 dicas:

 1) qual a melhor configuracao de discos (sas ou ssd, tipo de raid, etc);
 pelo menos espelhado vai ser raid1.
 2) tem que ser um xeon, ou um processador i7 six core com 12mb de cache
 atende?

 A pergunta é pq tenho que justificar a compra de servidor de 13, 15 mil
 reais, ou não.

 Jean Domingues.



-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Pegar nomes de colunas de um SQL qualquer

[Alexsander Rosa]

Estou fazendo uma procedure executa_relatorio que recebe os parâmetros da
GUI, executa e gera um CSV -- de modo similar ao que já existe na GUI, mas
quero fazer via procedure pra poder usar até no console. Consigo executar
normalmente, com parãmetros e tudo o mais, mas não consegui pegar os nomes
das colunas.

Exemplo:
CREATE TABLE relatorio (nome_relat text primary key, comando_sql text);
INSERT INTO relatorio VALUES ('USUARIOS', 'SELECT cod_usuario, nome_usuario
FROM usuario');

# SELECT sp_executa_relatorio('USUARIOS');
1, fulano
2, beltrano

Eu gostaria que a primeira linha fosse cod_usuario, nome_usuario.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Pegar nomes de colunas de um SQL qualquer

[Alexsander Rosa]

Em 27 de agosto de 2012 13:39, Nelson Luiz Gonzaga ngonz...@ig.com.brescreveu:


 É isso que voce quer:
 SELECT column_name FROM information_schema.columns WHERE table_name =


Eu já uso este, mas não serve no caso em questão porque o SQL pode ser
livre.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Pegar nomes de colunas de um SQL qualquer

[Alexsander Rosa]

Obrigado, vou investigar.

Em 27 de agosto de 2012 13:33, Dickson S. Guedes lis...@guedesoft.netescreveu:

 Em 27 de agosto de 2012 13:02, Alexsander Rosa
 alexsander.r...@gmail.com escreveu:
  Estou fazendo uma procedure executa_relatorio que recebe os parâmetros
 da
  GUI, executa e gera um CSV -- de modo similar ao que já existe na GUI,
 mas
  quero fazer via procedure pra poder usar até no console. Consigo executar
  normalmente, com parãmetros e tudo o mais, mas não consegui pegar os
 nomes
  das colunas.


 Talvez adaptando um pouco o seu código, você poderia utilizar
 a extensão colnames [1].


 [1] http://pgxn.org/dist/colnames/doc/colnames.html


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Licenças (era: firebirs X postgres)

[Alexsander Rosa]

Em 17 de agosto de 2012 20:00, Leandro Guimarães Faria Corcete DUTRA 
l...@dutras.org escreveu:

 Le 17/08/12 18:3-0300, Euler Taveira a écrit :

  na licença BSD você tem a *liberdade* de
  fazer o que bem entender. Você pode contra argumentar dizendo que é uma
  restrição para garantir a perpetuação da liberdade mas como afirmou
  Descartes, a liberdade é uma característica essencial da vontade e,
 assim
  sendo, devo possuir vontade (liberdade de escolha) para fazer qualquer
 coisa.

 Não, a vontade não é autônoma, o indivíduo vive em sociedade.  Ou seja,
 a liberdade só faz sentido dentro de um sistema de valores, ou acontece
 a atomização, que leva à lei da selva e à tirania.


Vida, Liberdade e Propriedade, os direitos humanos mais fundamentais de
todos.
Cada um pode fazer o que quiser, desde que não viole estes 3 direitos de
outrem.

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Script só com a estrutura do banco

[Alexsander Rosa]

pg_dump --schema-only
Fonte: man pg_dump

Em 15 de agosto de 2012 16:59, Edson Lidorio edson...@gmail.com escreveu:

 Boa tarde,

 Como faço para gerar um script só com a estrutura do banco, sem os dados?


 Edson


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tratamento de Contrabarra

[Alexsander Rosa]

Ou então grave um md5(senha||pitada_de_sal) no banco e compare o digest ao
invés da senha.

Em 7 de agosto de 2012 09:20, Anselmo Silva anselmo@gmail.comescreveu:

 Obrigado pelas dicas sobre SQL injection. Minha senha está criptografada
 na base e no SGDB. Não é permitido o uso do apóstrofo no login. Somente
 letras e números.
 Mas, em conclusão sobre o tema do tópico. Só tem jeito se tratar a
 aplicação nesse caso, né?


-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Views x ferramentas SCM (CVS, SVN, etc)

[Alexsander Rosa]

Neste caso eu não ficaria com as views em duplicidade no SCM, no DUMP geral
e na view individual?

Em 2 de agosto de 2012 19:58, Euler Taveira eu...@timbira.com escreveu:

 On 02-08-2012 18:16, Alexsander Rosa wrote:
  Como vocês armazenam as views em ferramentas SCM, considerando que o
  PostgreSQL expande e reformata tudo?
  E depois de armazenado, como fazer pra saber se a versão instalada no BD
 é a
  mesma que está no controle de versão?
 
 Se você vai utilizar a saída de ferramentas do PostgreSQL (aka pg_dump)
 como
 geradora do script, não formate. Ao invés disso, utilize algum dos vários
 formatadores de SQL quando você quiser ter uma apresentação melhor para
 suas
 visões. A partir da 9.2 a função que formata as visões sofreu melhorias
 (vide
 [1]).


 [1]

 http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=2f582f76b1945929ff07116cd4639747ce9bb8a1


 --
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




-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Views x ferramentas SCM (CVS, SVN, etc)

[Alexsander Rosa]

Como vocês armazenam as views em ferramentas SCM, considerando que o
PostgreSQL expande e reformata tudo?
E depois de armazenado, como fazer pra saber se a versão instalada no BD é
a mesma que está no controle de versão?

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] DUMP de procedures em arquivos separados

[Alexsander Rosa]

Hoje eu coloco no SVN um pg_dump com a estrutura do BD (--schema-only).
Cada vez que preciso mexer numa procedure tenho que selecionar a procedure
desejada, copiar e colar em algum editor, acrescentar o OR REPLACE depois
do CREATE e só então começar a fazer alguma coisa. E depois de pronta, a
procedure só entra no SVN via o pg_dump seguinte.

Eu gostaria que houvesse uma opção no pg_dump tipo
--procedures-in-separate-files que gerasse o DUMP sem as procedures;
estas, por sua vez, seriam gravadas em arquivos individuais chamados
nome-da-procedure.sql já com o OR REPLACE adicionado. Existe alguma
ferramenta que faça isso?

-- 
Atenciosamente,
Alexsander da Rosa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] DUMP de procedures em arquivos separados

[Alexsander Rosa]

1) Porque ./psql ao invés de psql ? Tem que estar no mesmo diretório do
psql?
2) A partir de que versão funciona?

Em 18 de julho de 2012 11:22, Matheus de Oliveira matioli.math...@gmail.com
 escreveu:


 --
 Matheus de Oliveira

 Bacharelado em Ciências de Computação
 Laboratório de Computação de Alto Desempenho - 
 LCADhttp://www.lcad.icmc.usp.br/
 Instituto de Ciências Matemáticas e de Computação - 
 ICMChttp://www.icmc.usp.br/
 Universidade de São Paulo - USP http://www.sc.usp.br/




 2012/7/18 Matheus de Oliveira matioli.math...@gmail.com



 2012/7/18 Alexsander Rosa alexsander.r...@gmail.com

 Hoje eu coloco no SVN um pg_dump com a estrutura do BD
 (--schema-only). Cada vez que preciso mexer numa procedure tenho que
 selecionar a procedure desejada, copiar e colar em algum editor,
 acrescentar o OR REPLACE depois do CREATE e só então começar a fazer
 alguma coisa. E depois de pronta, a procedure só entra no SVN via o
 pg_dump seguinte.


 Para isso você pode usar o \ef do psql, que já faz isso pra você, é só
 selecionar o editor (e.g. export EDITOR=vim) e executar:

 \ef nome da função


 Eu gostaria que houvesse uma opção no pg_dump tipo
 --procedures-in-separate-files que gerasse o DUMP sem as procedures;
 estas, por sua vez, seriam gravadas em arquivos individuais chamados
 nome-da-procedure.sql já com o OR REPLACE adicionado. Existe alguma
 ferramenta que faça isso?


 Não sei se tem algo assim pronto, mas não é difícil fazer se você aliar a
 tabela pg_proc e a função pg_get_functiondef.
 Exemplo:

 SELECT pg_get_functiondef(oid) FROM pg_proc WHERE proname = 'nome da
 função'

 Veja que o retorno será mais de uma linha se a função estiver
 sobrecarregada.


 Fiz um pequeno shell script pra isso. Vai ser útil pra mim também:

 #!/bin/bash

 ./psql $@ -A -t -F '|' -c 
 SELECT quote_ident(n.nspname) || '.' || quote_ident(p.proname) || '.' ||
 ROW_NUMBER() OVER(PARTITION BY n.nspname,p.proname) || '.sql', p.oid FROM
 pg_proc p JOIN pg_namespace n ON n.oid = p.pronamespace WHERE NOT
 p.proisagg AND n.nspname NOT LIKE 'pg_%' AND n.nspname 
 'information_schema' ORDER BY n.nspname, p.proname, p.oid;
  | while read LN; do
 ./psql $@ -A -t -c SELECT pg_get_functiondef(`echo $LN | cut -d '|'
 -f 2`)  `echo $LN | cut -d '|' -f 1`
 done

 Uso:

- salvar o texto acima num arquivo chamado get_functions.sh (ou
qualquer outro nome).
- executar:
chmod a+x get_functions.sh
- chamar o script da mesma forma como chamaria o psql. Exemplo:
/path/to/get_functions.sh -h host -p porta -U usuário banco
- serão gerados arquivos seguindo o modelo schema.func
name.id.sql no diretório corrente (id é um identificador simples e
sequencial, um para cada função sobrecarregada, se não tiver sobrecarga
será só 1).


 Mais fácil que isso impossível...=P


 Atenciosamente,
 --
 Matheus de Oliveira


 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
___
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 salvar usuario em log com trigger

[Alexsander Rosa]

Eu resolvo isso de uma maneira simples: coloco uma coluna usuário em
todas as tabelas que requerem este controle via log. Esta coluna equivale
ao último usuário que mexeu na tabela, e deve sempre ser atualizada junto
com qualquer outra coluna que seja modificada por algum usuário. Assim o
trigger pode usar o NEW.usuario para gravar nas tabelas de log e você ainda
tem de brinde o registro do último cidadão que mexeu naquele registro.

Em 11 de maio de 2012 15:30, Alessandro Lima grandegoia...@gmail.comescreveu:

 Tenho um aplicação web java + jdbc + postgresql 8.4
 Criei uma trigger para registrar log de qualquer alteração em certa tabela.
 Mas não encontrei uma forma registrar o usuario neste log, pois o usuario
 da aplicação é diferente do usuario do banco de dados,
 alias todos os usuarios da aplicação utilizam o mesmo usuario do postgres.

 Existe alguma forma de passar o usuario como parametro junto com INSERT,
 UPDATE, DELETE?
 Estou utilizando uma gambiarra, adicionando o codigo do usuario no final
 do sql na forma de comentario, exemplo: delete from tabela where codigo =
 1 --usuario:2

 Atenciosamente,

 Alessandro Lima


-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] Divisão de inteiros com resultado numeric

[Alexsander Rosa]

Sugiro incluir alguma segurança: calcule('true; TRUNCATE
tabela_importante') funciona.

Em 20 de maio de 2012 10:05, Matheus de Oliveira
matioli.math...@gmail.comescreveu:


 2012/5/20 Anselmo Silva anselmo@gmail.com

 Qual versão do PostgreSQL fizeste?

 Resultado:
 ao criar a função :
 AVISO:  uso de escape fora do padrão em cadeia de caracteres
 LINE 1: SELECT 'SELECT ' || regexp_replace(calculo, '([0-9]+)([^\.0-...

 ao executá-la usando: *Calcule ('1/10')*

 ERRO: erro de sintaxe em ou próximo a  
 SQL state: 42601
 Context: PL/pgSQL function calcule line 4 at comando EXECUTE



 Não era para usar o escape por padrão.

 Corrigindo para funcionar em qualquer versão:

 CREATE OR REPLACE FUNCTION public.calcule(calculo text)
 RETURNS numeric
 LANGUAGE plpgsql
 AS $function$
 DECLARE
 v_result numeric;
 BEGIN
 EXECUTE 'SELECT ' || regexp_replace(calculo, E'([0-9]+)([^\\.0-9])',
 E'\\1::numeric\\2', 'g')

 INTO v_result;
 RETURN v_result;
 END;
 $function$;

 Testado na 9.1. Não tive tempo ontem, mas vou explicar o que a função faz,
 como não testei muito pode ser que precise de ajustes. Esta função vai
 pegar todo número inteiro e colocar ::numeric na frente (para ver o
 resultado você pode usar um RAISE), em seguida dá um execute nesse
 resultado.

 Explicado a expressão regular, o padrão E'([0-9]+)([^\\.0-9])' vai
 procurar por caracteres de 0 a 9 seguidos de um caractere que *não* seja
 ponto (resumindo, um inteiro). O valor de substituição E'\\1::numeric\\2'vai 
 trocar o inteiro por ele mesmo mais o cast para numeric, e colocar de
 volta o caractere que não é ponto.

 Se for usar isso mesmo, faça um milhão de testes e ainda use try-catch na
 aplicação onde estiver usando, pois o que você passar também corre o risco
 de estar mal-formado. Apesar que estou achando essa função interessante
 para ser usada em fórmulas definidas pelo usuário.


 Atenciosamente,
 --
 Matheus de Oliveira


 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] Tratamento de DATAS

[Alexsander Rosa]

Acho que o que ele quer é apenas mostrar o nome do mês:
http://www.postgresql.org/docs/current/static/functions-formatting.html

SELECT to_char(CURRENT_DATE,'Month');

Em 3 de maio de 2012 12:14, Flavio Henrique Araque Gurgel 
fla...@4linux.com.br escreveu:


 Em 03-05-2012 11:47, Giovanni Sousa escreveu:
  Bom dia,
  Estou com uma dívida sobre o tratamento de datas, preciso retornar o mês
  por extenso. Há alguma função para tratar?
  Desde já agradeço
  Giovanni

 http://www.postgresql.org/docs/9.1/static/functions-datetime.html

 É pra versão 9.1. Veja a documentação da versão que está usando.
 Note que coisas literais em funções vão retornar em inglês.

 []s



 Flavio Henrique A. Gurgel
 Consultor e Instrutor 4Linux
 Tel: +55-11-2125-4747
 www.4linux.com.br
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] Replicação síncrona Posgresql

[Alexsander Rosa]

Não seria assíncrona neste caso?

Em 27 de abril de 2012 16:29, Leandro leandr...@gmail.com escreveu:

 Pessoal, boa tarde, configurei a replicação síncrona do 9.1 para testes,
 funcionou tudo beleza, mas fiquei com uma duvida. Caso o meu servidor slave
 por algum motivo  não consiga responder,  o servidor master fica esperando
 a resposta, mas qual a forma mais rápida e correta de  interromper esse
 recurso sem parar a produção? existe algum parâmetro para isso?
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] how instagram scales

[Alexsander Rosa]

E quanto à escolha entre foto no BD x foto no FS:

 The photos themselves go straight to Amazon S3, which currently stores
 several terabytes of photo data for us. We use Amazon CloudFront as our
 CDN, which helps with image load times from users around the world (like in
 Japan, our second most-popular country).


Em 14 de abril de 2012 14:29, Fábio Telles Rodriguez fabio.tel...@gmail.com
 escreveu:

 Olhem que interessante...


 destaques:

- Fabric http://fabric.readthedocs.org/en/1.3.3/index.html is used
to execute commands in parallel on all machines. A deploy takes only
seconds.
- PostgreSQL (users, photo metadata, tags, etc) runs on 12 Quadruple
Extra-Large memory instances.
- Twelve PostgreSQL replicas run in a different availability zone.
- PostgreSQL instances run in a master-replica setup using Streaming
Replication https://github.com/greg2ndQuadrant/repmgr. EBS is used
for snapshotting, to take frequent backups.
- XFS as the file system. Used to get consistent snapshots by freezing
and unfreezing the RAID arrays when snapshotting.
- Pgbouncer http://pgfoundry.org/projects/pgbouncer/ is used pool
connections http://thebuild.com/blog/ to PostgreSQL.




 http://highscalability.com/blog/2012/4/9/the-instagram-architecture-facebook-bought-for-a-cool-billio.html


 --
 Atenciosamente,
 Fábio Telles Rodriguez
 blog: http://www.midstorm.org/~telles/
 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




-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] Insert or Update

[Alexsander Rosa]

Em 9 de abril de 2012 10:56, Guimarães Faria Corcete DUTRA, Leandro 
l...@dutras.org escreveu:


 Algum motivo para recomendar uma documentação tão antiga?

 Melhor http://www.postgresql.org/docs/9.1/static/sql-insert.html


De qualquer forma nenhum dos links responde a pergunta dele...
A resposta é: Não, o PostgreSQL não tem UPSERT nem MERGE ainda.
Mas dá pra fazer com triggers, de uma forma não genérica:
http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE

-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] FUNÇÃO MD5

[Alexsander Rosa]

Deve ser conversão de tipo. A função md5() do PostgreSQL exige parâmetro
tipo text.

Em 4 de abril de 2012 12:25, José Mello Júnior
jose.mello.jun...@gmail.comescreveu:

 Em determinada aplicação utilizo diversas vezes chamada para essa função.
 Troquei o servidor de 8.2 para 8.4 e agora simplesmente não tenho mais essa
 função. O que posso fazer para manter a compatibilidade?


-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] Duvida Modelagem

[Alexsander Rosa]

Eu uso assim, separado por empresa, servidores diferentes.
Os pedidos começam do 1 a cada nova filial aberta ou CD criado.
Por exemplo, uma loja pode estar no pedido 327462/7 e outra no 879123/3.
O número depois da barra (na tela e onde mais é impresso) é o número da
filial.

Em 3 de abril de 2012 16:02, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:


 Em 3 de abril de 2012 15:41, Flávio Alves Granato 
 flavio.gran...@gmail.com escreveu:

 Fabrízio,

 Ainda concordo com o Dutra, não há motivos para separar as bases, mas
 também entendo o seu argumento de haver bases separadas para não parar a
 produtividade das filias. Mas realmente não vejo motivos para separar as
 bases, mesmo havendo a possibilidade de utilizar bases distintas entre
 filiais e matriz, pois ainda sim creio seria uma boa prática haver uma base
 centralizadora que não seja o DW ou Staging Area  ou outra qualquer voltada
 a reter dados históricos para um BI. Mas sempre vale avaliar os requisitos.


 Perfeito, mas não discordei do Dutra, apenas demonstrei que existem sim
 casos práticos em que existe sim essa *divisão* de bases de dados.

 E creio que existem ainda inúmeros cenários diferentes do meu exemplo com
 arquitetura similar. Mas claro que dependem dos seus requisitos...




-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] Armazenamento de Imagens

[Alexsander Rosa]

Pra mim a resposta à pergunta coloco as imagens no sistema de arquivos ou
no banco de dados? depende da probabilidade de manipulação em lote
destas imagens por terceiros (ou aplicações de terceiros). No caso das
fotos de produtos, já comentei que há vários casos em que as imagens serão
editadas, compartilhadas, etc. Se você colocar no BD e o cliente quiser
mexer na marca d'água, por exemplo, ou você exporta tudo depois importa
(ou seja, gravar no banco perdeu o sentido) ou você implementa um
mini-photoshop na sua aplicação.

Em 29 de março de 2012 10:57, Leandro DUTRA, Guimarães Faria Corcete 
l...@dutras.org escreveu:

 Le 2012-3-29 0h0, alecindro a écrit :
  Acompanhei essa discussão, mas não vi ninguém comentar que é
  recomendável ter uma tabela de dados específica para as fotos.
  Ex.: Não colocar a foto do foto do funcionário na tabela de cadastro do
  funcionário. Pois ao dar uma pesquisa nos dados nessa tabela , vai
  carrregar fotos juntas (select * - algum descuidado)

 Normalmente, eu não me preocuparia com isso.  Na aplicação, um erro
 desses vai aparecer (e ser eliminado) rapidinho.  Acho até bom, para
 pegar algum programador mais relaxado.  No uso eventual, não fará muita
 diferença.

Acho mais grave criar necessidade de mais uma junção, de longe!


 --
 skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
 +55 (11) 9406 7191ICQ/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




-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] Armazenamento de Imagens

[Alexsander Rosa]

E como faz se o cliente quiser mudar a marca d'água em todos os produtos?

Em 22 de março de 2012 08:23, Irineu iri...@senda.inf.br escreveu:

 Em 21/03/2012 13:35, Flavio Henrique Araque Gurgel escreveu:
  Nossa, que perigo... Se o cara errar qualquer coisa no ftp ou trocar
  um simples caractere do nome de um arquivo seu banco de dados não
  apontará mais pro arquivo certo. Eu sei que isso é prática comum,
  muita gente acha que banco de dados não é lugar de guardar arquivos,
  mas o risco é tremendo considerando os bancos de dados modernos.
 Concordo com o Flávio, na prática guardar arquivos no banco de dados
 vale a pena, tenho clientes com que usam um catalogo eletronico de
 produtos, com milhares de fotos, funciona perfeitamente com muita pouca
 manutenção e segurança, em 3 anos tive apenas 2 casos em que o arquivo
 ficou corrompido, foi só repor a foto e tudo certo.


-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] Armazenamento de Imagens

[Alexsander Rosa]

Ah, bom. Está explicado.

Em 22 de março de 2012 11:09, Irineu iri...@senda.inf.br escreveu:

  Em 22/03/2012 10:46, Alexsander Rosa escreveu:

 E como faz se o cliente quiser mudar a marca d'água em todos os produtos?

 Em 22 de março de 2012 08:23, Irineu iri...@senda.inf.br escreveu:

 Em 21/03/2012 13:35, Flavio Henrique Araque Gurgel escreveu:
  Nossa, que perigo... Se o cara errar qualquer coisa no ftp ou trocar
  um simples caractere do nome de um arquivo seu banco de dados não
  apontará mais pro arquivo certo. Eu sei que isso é prática comum,
  muita gente acha que banco de dados não é lugar de guardar arquivos,
  mas o risco é tremendo considerando os bancos de dados modernos.
  Concordo com o Flávio, na prática guardar arquivos no banco de dados
 vale a pena, tenho clientes com que usam um catalogo eletronico de
 produtos, com milhares de fotos, funciona perfeitamente com muita pouca
 manutenção e segurança, em 3 anos tive apenas 2 casos em que o arquivo
 ficou corrompido, foi só repor a foto e tudo certo.


  --
 Atenciosamente,
 Alexsander da Rosa
 http://rednaxel.com



 No meu caso não tenho esse requisito, dificilmente haverá uma troca de
 muitas imagens ao mesmo tempo.

 A maioria são desenhos técnicos(solados para calçados, peças metalicas,
 calçados) com alta resolução.

 Toda imagem é armazenada num cache na estação, todas elas geram uma chave
 hash md5.
 Se ela foi alterada, o aplicativo substitui a imagem no cache.



 --
 Irineu Raymundo
 Programador/Consultor Técnico
 Senda Engenharia de Dados Ltda.


 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] Armazenamento de Imagens

[Alexsander Rosa]

Requisitos da indústria são totalmente diferentes do comércio (atacado e
varejo).

Exemplos de casos de uso onde é preciso mudar/acessar várias imagens de uma
vez:
- mudança na marca d'água em todos os produtos
- catálogo novo do fornecedor com centenas de imagens novas
- agência de publicidade quer fazer um encarte promocional com centenas de
produtos
- desenvolvedor externo de e-commerce quer compartilhar as imagens no site
- empresa de mala-direta quer mandar SPAM com imagens dos produtos

Como eu disse, fotos de funcionários devem ficar no banco. Quanto aos
produtos, discordo.

-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] Armazenamento de Imagens

[Alexsander Rosa]

Eu optei por deixar as imagens dos produtos FORA do banco, num servidor
WEB, armazenando no banco apenas uma referência (nome do arquivo, por
exemplo). O motivo: outras aplicações podem usar as mesmas imagens
facilmente e, de brinde, o cliente (usuário) pode facilmente
alterar/consertar as imagens em lote e dar um FTP para o local determinado.

2012/3/20 Ronei Heck ro...@rhsistemas.com.br

 **
 Olá, Senhores(as),

 Necessito armazenar no banco de dados imagens de produtos e clientes.

 Qual o tipo de campo utilizado para isso?

 O que é melhor: criar uma tabela para fotos no mesmo banco de dados, ou
 criar um banco de dados só para as fotos? Se for no mesmo banco de dados
 das demais tabelas, haverá problema com backup?

 Muito obrigado.

 Ronei
 PostGres 8.3
 Clarion 6.1




-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] Currval

[Alexsander Rosa]

Em 21 de março de 2012 11:12, Marcelo Silva (IG) marc...@ig.com.brescreveu:

   Pessoal, mesmo lendo o manual ainda fiquei na dúvida...

 Ao executarmos um “select currval('minha_sequencia'::regclass) as cod_seq”

 Ele me traz a ultima alteracao depois de um next, mas a duvida é: ele traz
 a ultima alteração que eu fiz, ou que qualquer outro usuário fez?



Cada um enxerga a sua.

-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.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] Armazenamento de Imagens

[Alexsander Rosa]

Em 21 de março de 2012 13:35, Flavio Henrique Araque Gurgel 
fha...@gmail.com escreveu:

  Eu optei por deixar as imagens dos produtos FORA do banco, num servidor
 WEB,
  armazenando no banco apenas uma referência (nome do arquivo, por
 exemplo). O
  motivo: outras aplicações podem usar as mesmas imagens facilmente e, de
  brinde, o cliente (usuário) pode facilmente alterar/consertar as imagens
 em
  lote e dar um FTP para o local determinado.

 Nossa, que perigo...
 Se o cara errar qualquer coisa no ftp ou trocar um simples caractere
 do nome de um arquivo seu banco de dados não apontará mais pro arquivo
 certo.
 Eu sei que isso é prática comum, muita gente acha que banco de dados
 não é lugar de guardar arquivos, mas o risco é tremendo considerando
 os bancos de dados modernos.

 Se outras aplicações precisam das imagens, você poderia exportar de
 tempos em tempos para o sistema de arquivos.

 Mas enfim, ema ema ema, cada um com seus problemas (e soluções) :)


Eu rodo diariamente um script que identifica arquivos inexistentes. Além
disso, obviamente, a imagem aparece na tela de cadastro do produto (e nas
pesquisas). Na prática assim ficou bem mais fácil para o usuário.

Por exemplo: se ele resolver mudar a marca d'água em todos os 50 mil
produtos, pro sistema isto é transparente. Se uma agência de publicidade
quiser tratar todas as fotos, ok. Pro sistema tanto faz se o servidor web
é interno ou externo: se uma mala direta quiser usar as mesmas imagens,
tudo bem. Se uma empresa de e-commerce quiser usar as mesmas imagens no
site, sem problemas.

Quanto a errar um dígito e ficar com a imagem errada, se estivesse no banco
não faria diferença: o que impediria o usuário de carregar a imagem errada?
O software faria um reconhecimento de padrões pra saber que era pra ser
outro produto? Acredite, quando se fala de dezenas de milhares de produtos,
é mais fácil terceirizar isto. Não é questão de ser moderno ou não, é até
mais fácil armazenar no banco do que fora dele. A questão é fazer o esforço
extra para facilitar a vida do cliente.

Um caso diferente são as fotos de funcionários, estas sim devem estar no
banco.

-- 
Atenciosamente,
Alexsander da Rosa
http://rednaxel.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral