[pgbr-geral] Commit a cada Insert ou N registros?

2016-08-26 Thread sistemas 


Pessoal estou fazendo uma rotina (com loop) que exige update numa lista de 
registros, estou na dúvida se é melhor dar Commit a cada Insert ou a cada X 
registros, qual a carga que o Postgres aguenta sem dar Commit a cada 
registro?


Por exemplo, tenho um loop que atualiza 2mil registros (que irá aumentar a 
cada dia), dou o Commit a cada X registros ou só no final?
Eu gostaria de "Comitar" no final, caso alguma coisa de errado, não bagunço 
a base, mas minha preocupação é a memoria que isso pode usar, se é que ele 
usa a memoria e não uma tabela temporária no disco.




Marcelo

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

Re: [pgbr-geral] Commit a cada Insert ou N registros?

2016-08-26 Thread Douglas Fabiano Specht 
Em 26 de agosto de 2016 10:29,  escreveu:

>
> Pessoal estou fazendo uma rotina (com loop) que exige update numa lista de
> registros, estou na dúvida se é melhor dar Commit a cada Insert ou a cada X
> registros, qual a carga que o Postgres aguenta sem dar Commit a cada
> registro?
>
> Por exemplo, tenho um loop que atualiza 2mil registros (que irá aumentar a
> cada dia), dou o Commit a cada X registros ou só no final?
> Eu gostaria de "Comitar" no final, caso alguma coisa de errado, não
> bagunço a base, mas minha preocupação é a memoria que isso pode usar, se é
> que ele usa a memoria e não uma tabela temporária no disco.
>
>
>
> Marcelo
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


bom dia Marcelo,
nos aqui na empresa tínhamos um problema de performance qdo efetuávamos uma
grande quantidade de insert e efetuando commit registro a registro.
Atualmente mudamos para 5000 registros e melhorou muito.
mas por que 5000? como utilizamos multi-banco, acho que foi imposição do
sql server 2008(se nao me engano) de só aceitar essa quantidade.

pense no seguinte:

insert into table values (1,1),(1,2),(1,3),(2,1);

e não
insert into table values (1,1);
insert into table values (1,2);
insert into table values (1,3);
insert into table values (2,1);

claro que você pode efetuar um teste de mesa bem simples e tirar as suas
conclusões no seu ambiente.


-- 

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

Re: [pgbr-geral] Commit a cada Insert ou N registros?

2016-08-26 Thread sistemas 
From: Douglas Fabiano Specht 
Sent: Friday, August 26, 2016 11:16 AM
To: Comunidade PostgreSQL Brasileira 
Subject: Re: [pgbr-geral] Commit a cada Insert ou N registros?



Em 26 de agosto de 2016 10:29,  escreveu:


  Pessoal estou fazendo uma rotina (com loop) que exige update numa lista de 
registros, estou na dúvida se é melhor dar Commit a cada Insert ou a cada X 
registros, qual a carga que o Postgres aguenta sem dar Commit a cada registro?

  Por exemplo, tenho um loop que atualiza 2mil registros (que irá aumentar a 
cada dia), dou o Commit a cada X registros ou só no final?
  Eu gostaria de "Comitar" no final, caso alguma coisa de errado, não bagunço a 
base, mas minha preocupação é a memoria que isso pode usar, se é que ele usa a 
memoria e não uma tabela temporária no disco.



  Marcelo

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

bom dia Marcelo,
nos aqui na empresa tínhamos um problema de performance qdo efetuávamos uma 
grande quantidade de insert e efetuando commit registro a registro.
Atualmente mudamos para 5000 registros e melhorou muito.
mas por que 5000? como utilizamos multi-banco, acho que foi imposição do sql 
server 2008(se nao me engano) de só aceitar essa quantidade.

pense no seguinte:

insert into table values (1,1),(1,2),(1,3),(2,1);


e não
insert into table values (1,1);

insert into table values (1,2);

insert into table values (1,3);

insert into table values (2,1);


claro que você pode efetuar um teste de mesa bem simples e tirar as suas 
conclusões no seu ambiente.


-- 


Douglas Fabiano Specht

Obrigado pela resposta Douglas, eu fiz uns testes aqui e relamente commit em 
bloco é mais rápido, minha duvida é com relação a quantidade de registros que 
posso manter em cache antes do commit, eu gostaria que, se a transação desse 
algum erro ele não alterasse nada, pois se der um erro vou pedir ao usuario 
para executar a rotina novamente após a correção, mas vou ter que estudar 
melhor isso, pois creio que haja um limite nesse bloco, nada que umas 
validações a mais não resolva.


Marcelo



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

Re: [pgbr-geral] Commit a cada Insert ou N registros?

2016-08-26 Thread Osvaldo Kussama 
Em 26/08/16, siste...@mvsoftware.com.br escreveu:
> From: Douglas Fabiano Specht
> Sent: Friday, August 26, 2016 11:16 AM
> To: Comunidade PostgreSQL Brasileira
> Subject: Re: [pgbr-geral] Commit a cada Insert ou N registros?
>
>
> Obrigado pela resposta Douglas, eu fiz uns testes aqui e relamente commit em
> bloco é mais rápido, minha duvida é com relação a quantidade de registros
> que posso manter em cache antes do commit, eu gostaria que, se a transação
> desse algum erro ele não alterasse nada, pois se der um erro vou pedir ao
> usuario para executar a rotina novamente após a correção, mas vou ter que
> estudar melhor isso, pois creio que haja um limite nesse bloco, nada que
> umas validações a mais não resolva.
>


Note que se você fizer COMMIT a cada n registros e der algum problema
muito provavelmente você já terá permanentemente em sua base os
registros já commitados.
Não será possível simplesmente reexecutar a rotina. A rotina tem que
saber a partir de que ponto ela deve continuar o processamento.
Uma possível solução é você imprimir a cada COMMIT a quantidade de
registros já processados e, em caso de reprocessamento, informar ao
programa quantos registros ele deve saltar.

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

[pgbr-geral] RES: RES: RES: RES: Chave Primaria Composta

2016-08-26 Thread Márcio A . Sepp 

> > Vários anos atrás vi na lista o Dutra falando sobre isso também e
> > participei das discussões afim de aprender mais. Pois até o momento
> > sempre usei ID's também.
> >
> > Tenho um produto ERP com mais ou menos 1.000 tabelas e refiz todas
> > para chaves naturais. Os pontos positivos e negativos que o Adami
> > citou também valeram para o meu caso.
> 
> Acho que vocês não sabem como isso me deixa feliz!

Então fique novamente, pois tbm estou nessa. 
Obrigado novamente!


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

Re: [pgbr-geral] RES: Chave Primaria Composta

2016-08-26 Thread Tiago José Adami 
2016-08-26 0:30 GMT-03:00 Euler Taveira :
> On 25-08-2016 14:17, Tiago José Adami wrote:
>>Também há 2 triggers um pouco mais complexos que não permitem
>>horários conflitantes, algo impossível de tratar apenas com FKs.
>>
> Você tentou usar range types [1] e/ou restrições de exclusão [2] (ex. [3])?
>
> [1] https://www.postgresql.org/docs/9.6/static/rangetypes.html
> [2]
> https://www.postgresql.org/docs/9.6/static/sql-createtable.html#SQL-CREATETABLE-EXCLUDE
> [3]
> http://stackoverflow.com/questions/10759531/exclusion-constraint-with-overlapping-timestamp-range#10760028

Inicialmente a implementação dos triggers foi feita ainda quando as
chaves primárias eram compostas e era necessário validar junto as
chaves realmente naturais (em campos fora das PKs) pelo código dos
triggers. Depois de migrar as tabelas para usar chaves naturais
simplesmente ajustei o código no tocante às chaves e tudo funcionou
perfeitamente, portanto não procurei algo para substituir os triggers.

Agora que as tabelas possuem chaves naturais adequadas e o projeto
está quase homologado, vou me planejar para investir um tempo nisso.

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

Re: [pgbr-geral] Commit a cada Insert ou N registros?

2016-08-26 Thread Euler Taveira 
On 26-08-2016 10:29, siste...@mvsoftware.com.br wrote:
> Pessoal estou fazendo uma rotina (com loop) que exige update numa lista
> de registros, estou na dúvida se é melhor dar Commit a cada Insert ou a
> cada X registros, qual a carga que o Postgres aguenta sem dar Commit a
> cada registro?
> 
Uma transação *não* pode conter mais do que 2³²-2 comandos SQL.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Chave Primaria Composta

2016-08-26 Thread Silfar Goulart 
Eu prefiro sempre criar uma chave primaria como ID que uso para
relacionamentos. E uso chaves Uniques para evitar duplicidade. Para mim é a
melhor maneira.



Enviado com MailTrack


Silfar Goulart

Em 26 de agosto de 2016 13:03, Tiago José Adami 
escreveu:

> 2016-08-26 0:30 GMT-03:00 Euler Taveira :
> > On 25-08-2016 14:17, Tiago José Adami wrote:
> >>Também há 2 triggers um pouco mais complexos que não permitem
> >>horários conflitantes, algo impossível de tratar apenas com FKs.
> >>
> > Você tentou usar range types [1] e/ou restrições de exclusão [2] (ex.
> [3])?
> >
> > [1] https://www.postgresql.org/docs/9.6/static/rangetypes.html
> > [2]
> > https://www.postgresql.org/docs/9.6/static/sql-createtable.html#SQL-
> CREATETABLE-EXCLUDE
> > [3]
> > http://stackoverflow.com/questions/10759531/exclusion-
> constraint-with-overlapping-timestamp-range#10760028
>
> Inicialmente a implementação dos triggers foi feita ainda quando as
> chaves primárias eram compostas e era necessário validar junto as
> chaves realmente naturais (em campos fora das PKs) pelo código dos
> triggers. Depois de migrar as tabelas para usar chaves naturais
> simplesmente ajustei o código no tocante às chaves e tudo funcionou
> perfeitamente, portanto não procurei algo para substituir os triggers.
>
> Agora que as tabelas possuem chaves naturais adequadas e o projeto
> está quase homologado, vou me planejar para investir um tempo nisso.
>
> TIAGO J. ADAMI
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Chave Primaria Composta

2016-08-26 Thread Guimarães Faria Corcete DUTRA , Leandro 
2016-08-26 13:40 GMT-03:00 Silfar Goulart :
>
> Eu prefiro sempre criar uma chave primaria como ID que uso para 
> relacionamentos. E uso chaves Uniques para evitar duplicidade. Para mim é a 
> melhor maneira.

Melhor por quê, se teu modelo fica mais pesado (mais índices) e mais
difícil de usar (mais junções)?

Claro que tens todo o direito de ter opiniões, ainda mais para a tua
situação específica, mas ajuda os outros se as fundamentares.



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Commit a cada Insert ou N registros?

2016-08-26 Thread sistemas 



-Mensagem Original- 
From: Osvaldo Kussama

Sent: Friday, August 26, 2016 11:42 AM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral] Commit a cada Insert ou N registros?

Em 26/08/16, siste...@mvsoftware.com.br 
escreveu:

From: Douglas Fabiano Specht
Sent: Friday, August 26, 2016 11:16 AM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral] Commit a cada Insert ou N registros?


Obrigado pela resposta Douglas, eu fiz uns testes aqui e relamente commit 
em

bloco é mais rápido, minha duvida é com relação a quantidade de registros
que posso manter em cache antes do commit, eu gostaria que, se a transação
desse algum erro ele não alterasse nada, pois se der um erro vou pedir ao
usuario para executar a rotina novamente após a correção, mas vou ter que
estudar melhor isso, pois creio que haja um limite nesse bloco, nada que
umas validações a mais não resolva.




Note que se você fizer COMMIT a cada n registros e der algum problema
muito provavelmente você já terá permanentemente em sua base os
registros já commitados.
Não será possível simplesmente reexecutar a rotina. A rotina tem que
saber a partir de que ponto ela deve continuar o processamento.
Uma possível solução é você imprimir a cada COMMIT a quantidade de
registros já processados e, em caso de reprocessamento, informar ao
programa quantos registros ele deve saltar.

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


Sim, o detalhe é mais performance e o quanto posso manter em cache antes de 
comitar, eu já mantenho um campo status mostrando que aquele registro foi 
anterado, como hoje faço registro a registro esse campo status me ajuda no 
reprocesso, o que estou estudando é comitar todo o processo de uma vez ou a 
cada N registros, eu prefero ao final do processo porque se der um erro 
posso dizer ao usuario que nada mudou, mas se não der vou ter que fazer um 
controle do que foi alterado elo campo status e numero de processo.



Marcelo 


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

Re: [pgbr-geral] Commit a cada Insert ou N registros?

2016-08-26 Thread sistemas 



-Mensagem Original- 
From: Euler Taveira

Sent: Friday, August 26, 2016 1:34 PM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral] Commit a cada Insert ou N registros?

On 26-08-2016 10:29, siste...@mvsoftware.com.br wrote:

Pessoal estou fazendo uma rotina (com loop) que exige update numa lista
de registros, estou na dúvida se é melhor dar Commit a cada Insert ou a
cada X registros, qual a carga que o Postgres aguenta sem dar Commit a
cada registro?


Uma transação *não* pode conter mais do que 2³²-2 comandos SQL.


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


Opa acho que era isso que eu precisava saber, existe um limite e não é 
somente a memória do servidor!


Obrigado Euler


Marcelo 


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

[pgbr-geral] Script para backup

2016-08-26 Thread Ricardo 
Boa tarde pessoal,

Na versão 9.1 eu usava o scrip abaixo para gerar o backup dos banco, porém 
depois que instalei o postgres 9.5 está dando erro de autenticação.
Estou usando a mesma senha e usuário que uso pra autenticar no PgAdmin e 
também para conectar o banco via aplicação.

Alguém pode me dar uma ajuda.
Obrigado pela atenção
Ricardo

@echo off
Set PGUSER=%2
Set PGPASSWORD=%3
@echo on
C:\PostgreSQL\9.3\bin\pg_dump.exe --host localhost --port 5432 --username 
"postgres" --no-password  --format tar --blobs --verbose --file "%1" "Reserva"
@echo off
pause
@echo on___
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 para backup

2016-08-26 Thread Alexsandro Haag 

Em 26/08/2016 15:34, Ricardo escreveu:

Boa tarde pessoal,
Na versão 9.1 eu usava o scrip abaixo para gerar o backup dos 
banco, porém depois que instalei o postgres 9.5 está dando erro de 
autenticação.
Estou usando a mesma senha e usuário que uso pra autenticar no 
PgAdmin e também para conectar o banco via aplicação.

Você revisou o pg_hba.conf da sua nova instalação?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Script para backup

2016-08-26 Thread Ricardo 


From: Alexsandro Haag 
Sent: Friday, August 26, 2016 3:52 PM
To: pgbr-geral@listas.postgresql.org.br 
Subject: Re: [pgbr-geral] Script para backup

Em 26/08/2016 15:34, Ricardo escreveu:

  Boa tarde pessoal,

  Na versão 9.1 eu usava o scrip abaixo para gerar o backup dos banco, 
porém depois que instalei o postgres 9.5 está dando erro de autenticação.
  Estou usando a mesma senha e usuário que uso pra autenticar no PgAdmin e 
também para conectar o banco via aplicação.

Você revisou o pg_hba.conf da sua nova instalação? 




Aparentemente o problema estava nas aspas do usuário, mudei de “postgres” para 
postgres e não deu o erro, vou fazer mais teste e dou um retorno.

Valeu
___
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 para backup

2016-08-26 Thread Guimarães Faria Corcete DUTRA , Leandro 
2016-08-26 16:09 GMT-03:00 Ricardo :
> From: Alexsandro Haag
> Em 26/08/2016 15:34, Ricardo escreveu:
> Na versão 9.1 eu usava o scrip abaixo para gerar o backup dos banco,
> porém depois que instalei o postgres 9.5 está dando erro de autenticação.
> Estou usando a mesma senha e usuário que uso pra autenticar no PgAdmin e
> também para conectar o banco via aplicação.
>
> Você revisou o pg_hba.conf da sua nova instalação?
> 
>
> Aparentemente o problema estava nas aspas do usuário, mudei de “postgres”
> para postgres e não deu o erro, vou fazer mais teste e dou um retorno.

Pessoal, por favor cortem rodapés, cabeçalhos, escrevam em texto
simples com as marcas de citação adequadas; se alguém escrever com
formatação, por favor convertam em texto simples antes de responder.
Fica muito ruim ler mensagens como a acima — e olhem que já limpei
rodapés e cabeçalhos!


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Função Seleciona todas tabelas com coluna especifica

2016-08-26 Thread Bruno Felipe 
Boa tarde pessoal, estou executando uma função que percorre todas as
tabelas filtrado por uma coluna especifica e depois atualiza a coluna por
um valor rondando no laço de repetição. porém está dando um erro que não
consigo identificar

CREATE OR REPLACE FUNCTION alteraEmpresa () RETURNS void  LANGUAGE
'plpgsql' AS $$
DECLARE

tabela record ;
BEGIN
FOR tabela in SELECT table_name  FROM information_schema.columns WHERE
table_name in (select tablename from pg_tables where schemaname = 'public'
order by 1)
   and column_name = 'IdEmpresa'  order by 1
LOOP
UPDATE tabela.table_name SET "IdEmpresa" = 1;
END LOOP;

END;
$$

SELECT alteraEmpresa();


ERRO:  esquema "tabela" não existe
LINE 1: UPDATE tabela.table_name SET "IdEmpresa" = 1
   ^
QUERY:  UPDATE tabela.table_name SET "IdEmpresa" = 1
CONTEXT:  PL/pgSQL function alteraempresa() line 10 at comando SQL



como posso resolver?


--
___
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 Seleciona todas tabelas com coluna especifica

2016-08-26 Thread Flavio Henrique Araque Gurgel 
Em sex, 26 de ago de 2016 às 17:30, Bruno Felipe 
escreveu:

> Boa tarde pessoal, estou executando uma função que percorre todas as
> tabelas filtrado por uma coluna especifica e depois atualiza a coluna por
> um valor rondando no laço de repetição. porém está dando um erro que não
> consigo identificar
>
> CREATE OR REPLACE FUNCTION alteraEmpresa () RETURNS void  LANGUAGE
> 'plpgsql' AS $$
> DECLARE
>
> tabela record ;
> BEGIN
> FOR tabela in SELECT table_name  FROM information_schema.columns WHERE
> table_name in (select tablename from pg_tables where schemaname = 'public'
> order by 1)
>and column_name = 'IdEmpresa'  order by 1
> LOOP
> UPDATE tabela.table_name SET "IdEmpresa" = 1;
> END LOOP;
>
> END;
> $$
>
> SELECT alteraEmpresa();
>
>
> ERRO:  esquema "tabela" não existe
> LINE 1: UPDATE tabela.table_name SET "IdEmpresa" = 1
>^
> QUERY:  UPDATE tabela.table_name SET "IdEmpresa" = 1
> CONTEXT:  PL/pgSQL function alteraempresa() line 10 at comando SQL
>
>
>
> como posso resolver?
>
> Você está tentando fazer um update dinâmico, use EXECUTE :
EXECUTE 'UPDATE ' || tabela.table_name || ' SET "idEmpresa" = 1' ;

[]s
Flavio Gurgel
___
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 Seleciona todas tabelas com coluna especifica

2016-08-26 Thread Bruno Felipe 
Blz, resolvido! Valeu!
Em 26/08/2016 19:48, "Flavio Henrique Araque Gurgel" 
escreveu:

>
>
> Em sex, 26 de ago de 2016 às 17:30, Bruno Felipe <
> bruno.dc.fel...@gmail.com> escreveu:
>
>> Boa tarde pessoal, estou executando uma função que percorre todas as
>> tabelas filtrado por uma coluna especifica e depois atualiza a coluna por
>> um valor rondando no laço de repetição. porém está dando um erro que não
>> consigo identificar
>>
>> CREATE OR REPLACE FUNCTION alteraEmpresa () RETURNS void  LANGUAGE
>> 'plpgsql' AS $$
>> DECLARE
>>
>> tabela record ;
>> BEGIN
>> FOR tabela in SELECT table_name  FROM information_schema.columns WHERE
>> table_name in (select tablename from pg_tables where schemaname = 'public'
>> order by 1)
>>and column_name = 'IdEmpresa'  order by 1
>> LOOP
>> UPDATE tabela.table_name SET "IdEmpresa" = 1;
>> END LOOP;
>>
>> END;
>> $$
>>
>> SELECT alteraEmpresa();
>>
>>
>> ERRO:  esquema "tabela" não existe
>> LINE 1: UPDATE tabela.table_name SET "IdEmpresa" = 1
>>^
>> QUERY:  UPDATE tabela.table_name SET "IdEmpresa" = 1
>> CONTEXT:  PL/pgSQL function alteraempresa() line 10 at comando SQL
>>
>>
>>
>> como posso resolver?
>>
>> Você está tentando fazer um update dinâmico, use EXECUTE :
> EXECUTE 'UPDATE ' || tabela.table_name || ' SET "idEmpresa" = 1' ;
>
> []s
> Flavio Gurgel
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Chave Primaria Composta

2016-08-26 Thread Reijanio Nunes Ribeiro 
Em meu sistema a parte de controle devusuarios é composta nunca tive
problemas
Em 25/08/2016 11:06, "Gustavo"  escreveu:

>
> mais um detalhe, com a chave composta
> evita um monte de triggers para ajuste de algumas informações também,
> erros de programação
> e menos manutenção
> ᐧ
>
> Em 25 de agosto de 2016 10:56, Guimarães Faria Corcete DUTRA, Leandro <
> l...@dutras.org> escreveu:
>
>> 2016-08-25 10:49 GMT-03:00 Gustavo :
>> >
>> > Razão, seria as lendas urbanas que sempre eu via sobre isso...
>>
>> Boa definição.
>>
>>
>> > agora você me dizendo que é uma otima ideia  ja até pensei em uma chave
>> primaria com 3 campos
>>
>> Não há limite, exceto praticidade.  E mesmo assim, às vezes deixa-se
>> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma
>> chave com, digamos, quatro ou cinco atributos por tabelas filhas
>> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções
>> e índices que uma chave natural economiza.
>>
>>
>> > vamos analisar da seguinte maneira. se não fosse uma boa prática não
>> teria essa opção para ser usada no banco de dados...
>>
>> Infelizmente essa lógica nem sempre se aplica.  Por exemplo, herança
>> geralmente não é boa idéia, pelo menos não no modelo lógico; no modelo
>> físico, foi útil para gambiarrar particionamento de tabelas.
>>
>>
>> --
>> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
>> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
>> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
>> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral