Re: [pgbr-geral] VIEWS com parâmetro

[Fabrízio de Royes Mello]

On 05-02-2014 15:01, Daniel Cordeiro wrote:


Obrigado pela correção Euler. Na ânsia de explicar uma forma de executar
o que se tinha interesse escrevi sem nem pensar na reescrita feita pelo
planejador antes da execução. Serei mais cuidadoso nas próximas!

Acontece que minha realidade para a consulta que impulsionou a escolha
por uma procedure ao invés de uma visão é bem diferente da exposta no
início deste tópico. Minha consulta possui diversas subqueryes com
definições de parâmetros  e cálculos  que não puderam ser
solucionados/otimizados com uso de CTEs ou views (e se tornou
impraticável para o momento a reescrita do modelo de negócio do banco).
E não apenas encapsular uma única condição.

Claro, sempre existe uma forma melhor de se fazer, o limite neste
contexto esta no meu 'universo conhecido' ;-P.



Daniel,

Creio que vc compreendeu bem porque o pessoal lhe indicou simplesmente 
criar uma VIEW e que a mesma sofre um processo de reescrita antes de ser 
executada, e com isso obtemos performance.


Então se mesmo assim vc precisa de um "parametro" em sua view, creio que 
podes usar as funções "set_config" e "current_setting" [1] para criar 
uma variável de sessão (ou use a extensão session_variables [2]).


Exemplo:

CREATE VIEW v_foo AS SELECT * FROM foo WHERE codigo = 
current_setting('foo.codigo')::INTEGER;


Para executar:

SELECT set_config('foo.codigo', '1', false);
SELECT * FROM v_foo;

Não sei se isso lhe ajudará, até porque não compreendi bem o seu 
problema de usar uma VIEW sem isso, e também tem a questão que vc terá 
se "setar" na sessão o valor do seu parâmetro...


Att,

[1] http://www.postgresql.org/docs/current/static/functions-admin.html
[2] http://pgxn.org/dist/session_variables/0.0.4/

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

Re: [pgbr-geral] Pacote Senha Invalido

[Matheus de Oliveira]

2014-02-05 Enio :

> Valeu pela dica Matheus, sem ela iria demorar mais a chegar no problema.
>
>
>
De nada... :-)

A lista está aí para isso, ajudar os outros...


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

Re: [pgbr-geral] VIEWS com parâmetro

[Matheus de Oliveira]

2014-02-05 Daniel Cordeiro :

>
> Em 05-02-2014 11:55, Matheus de Oliveira escreveu:
>  ...
>
> ', uma vez que a view vai gerar todos os dados e só depois é que o
> planejador realizará a restrição através do cláusula
>
>

> WHERE e ordenações necessárias.
>
>>
>>
>  humm... Sua afirmação não está correta. [...]
> Eu até diria que nesse exemplo específico a view me parece até mais
> adequada e mais fácil de manter do que a função.
>
>Como eu falei no email que respondi para Euler: My bad :-(
>

Tranquilo, acontece. Só corrigi para não deixar erros assim no histórico...
:-)


>
>>  Minha sugestão é criar uma função que realiza a consulta já adicionando
>> as restrições necessárias para a triagem inicial dos dados desejados.
>> [...]
>>
>> Eu só recomendaria, nesse caso especificamente, a usar uma função SQL ao
>> invés de PL/pgSQL:
>>
>> CREATE OR REPLACE FUNCTION sp_lancamentos(IN CODCONTA varchar)
>> RETURNS TABLE(i int, c1 text,c2 text, c text)
>> AS $$
>> SELECT id,conta,campo1,campo2 FROM lancamentos WHERE conta =
>> CODCONTA;
>> $$
>> LANGUAGE SQL;
>>
>>  Para chamá-la:
>
>  SELECT * FROM sp_lancamentos('Produtivo');
>
>  (a chamada em si seria igual à PL/pgSQL, só quis exemplificar)]
>
> Claro, usei o plpgsql por me basear em algo que já tinha, e o mesmo
> depende dos recursos além da sql.
>
>

Ah sim, entendo muito bem. Só quis deixar claro que quando queremos
**simples**mente uma espécie de "view parametrizada" a troca natural é para
uma função em linguagem SQL. Na verdade foi mais um complemento à sua
resposta.


>
>
>>  Para uma function  muito grande e com muitas variáveis para
>> substituição, vale a pena utilizar a cláusula EXECUTE no RETURN QUERY (isso
>> já me salvou de vários problemas em functions com mais mais de 1500 linhas
>> e código e dezenas de variáveis)* 2*:
>>
>>
>> *  RETURN QUERY EXECUTE 'SELECT id,conta,campo1,campo2 FROM
>> lancamentos WHERE conta = $1' USING CODCONTA;*
>> 
>>
>>
>>
>  Ah? Por quê? Eu particularmente tento evitar o EXECUTE ao menos que
> estritamente necessário. Lembre-se que ele não pode ser otimizado pelo
> PL/pgSQL para armazenar o plano de execução.
>
>Eu também não. Mas neste meu caso, após o crescimento de dados em
> alguns clientes (alguns milhões de registros em dezenas de tabelas), o
> QueryPlan dentro da procedure passou a ser tratado de maneira totalmente
> diferente  se comparado à execução da mesma query já com os valores
> prefixados nas condicionais e subqueryes fora da procedure. Aparentemente,
> como o prepare acontece antes do conhecimento dos parâmetros na procedure,
> o planejador gerava um plano de execução mais custoso. (novamente, esta foi
> a minha impressão sobre o caso).
>
> Estou falando da mesma consulta rodando em 5 horas dentro da procedure e 7
> segundos rodando fora. Inicialmente pensei que fosse a adoção do RETURN
> QUERY. Ao modificar a procedure fazendo o retorno com o EXECUTE, o tempo
> foi normalizado e o custo de operação dentro e fora da procedure ficou, de
> fato, irrelevante.
>
>
Sim, isso realmente poderia acontecer. Creio que o seu caso foi numa versão
anterior à 9.2, correto?

Na 9.2 o modelo de gerar plano de execução para "prepared statements"
mudou, e ficou bem melhor. Agora o plano é gerado no EXECUTE, quando já são
conhecidos os valores. Recomendo você a testar novamente essas funções numa
versão mais recente (9.2 ou 9.3) e verificar se o comportamento ainda é o
mesmo. Se o fizer, por favor compartilhe os resultados com os colegas,
;-)...


>
>
>
>>  Lembrando que estas ações podem dificultar a análise de um problema
>> futuro, pois o EXPLAIN não vai detalhar o conteúdo interno executado na
>> função e nem nos logs.
>>
>>
>  +1. Otimizar funções é uma tarefa bem árdua. Só uma dica, a extensão
> auto_explain pode ajudar nessa tarefa. ;-)
>
>
> Obrigado pela dica! Vou estudar a extensão para verificar sua adoção em
> nosso ambiente.
>
>
É, na minha opinião, um pré-requisito para quem usa muitas funções.

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

Re: [pgbr-geral] VIEWS com parâmetro

[Matheus de Oliveira]

2014-02-05 Matheus Saraiva :

>
> Em 05-02-2014 17:02, Douglas Fabiano Specht escreveu:
>
>
>
>
> Em 5 de fevereiro de 2014 16:40, Matheus Saraiva <
> matheus.sara...@gmail.com> escreveu:
>
>> Em 05-02-2014 12:54, Euler Taveira escreveu:
>>
>>  On 05-02-2014 11:32, Matheus Saraiva wrote:
>>>
 Quero deixar a clausula where encapsulada na view e na chamada da view
 eu passaria apenas o nome 'matheus', 'paulo', 'joão', etc

  E você pode deixar condições da cláusula WHERE encapsuladas na VIEW.
>>> Por
>>> exemplo:
>>>
>>> CREATE VIEW funcionarios_ativos AS SELECT nome, salario FROM
>>> funcionarios WHERE status = TRUE;
>>>
>>> SELECT * FROM funcionarios_ativos WHERE nome = 'foo';
>>>
>>> Ele apresentará somente funcionários cujo nome é 'foo' e que estejam
>>> "ativos". O que a visão faz é mesclar o SELECT que a definiu com o
>>> SELECT na qual ela foi utilizada. Portanto, internamente temos uma
>>> reescrita da consulta para:
>>>
>>> SELECT nome, salario FROM funcionarios WHERE status = TRUE AND nome =
>>> 'foo';
>>>
>>> Observe que *somente* as colunas mencionadas na definição da visão são
>>> apresentadas.
>>>
>>>
>>>
>>  E se eu quisesse não escrever nenhum WHERE na linha que chama a VIEW?
>> Algo como:
>>
>>
>> CREATE VIEW funcionarios_ativos AS SELECT nome, salario FROM
>>  funcionarios WHERE nome = (VALOR SERÁ PASSADO NA CHAMADA DA VIEW);
>>
>> SELECT * FROM funcionarios_ativos (VALOR QUE SERÁ USADO NO WHERE
>> ENCAPSULADO);
>>
>> Como ficaria?
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
> Mateus
> explique melhor por que vc precisa ser dessa maneira, pois diretamente na
> view nao é possivel, somente criando uma função para isso.
>
> Quero fazer o que o Matheus Oliveira fez, porém, com VIEW. Meu objetivo
> com isso é minimizar o máximo possível o tamanho da linha ao chamar a view.
> Vi que isso pode ser feito com funções, mas trabalhar com VIEW é mais
> prático. Resumindo quero deixar tudo encapsulado sem ter que escrever
> clausula WHERE na linha de chamada da view. Quero apenas passar o nome da
> view e o valor que será usado no filtro where que está dentro da view.
> Igualmente como eu faria se fosse uma função: SELECT * FROM
> sp_teste('TESTANDO');.
> Mas pelo que vejo, view não suporta isso. Sendo possível apenas com função.
>
>
Exatamente, não aceita. Não há muito mais que possamos fazer aqui. Só
repense bem se vale a pena ficar criando muitas funções só para economizar
algumas palavras no WHERE. Ok?


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

Re: [pgbr-geral] VIEWS com parâmetro

[Rafael Fialho Corrêa]

Em 5 de fevereiro de 2014 18:49, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> Ela é uma função que devolve uma relação derivada, só não tem esse
>
nome.  Mas, se teu ambiente for estranho demais, sempre podes usar uma
> função tradicional, que é bem mais chatinha.
>
> Alguém me corrija se eu tiver falado bobagem, estou afastado da
> programação há tanto tempo...


Além disso, funções com tipos específicos de retorno irão ficar
"engessadas", e toda manutenção a ser realizada (novos filtros, novos
campos, etc.), além de possivelmente ser custoso e gerar reflexos
indesejados, pode gerar os famosos "bad smells".

A não ser que seja algo muito elaborado, que não pode ser corretamente
otimizado/desenvolvido via SQL, eu não usaria função pra este caso, mas..
"cá um, cá um" né?
___
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 com parâmetro

[Guimarães Faria Corcete DUTRA , Leandro]

2014-02-05 Matheus Saraiva :
>
> Em 05-02-2014 17:44, Euler Taveira escreveu:
>
>> Vejo que você não compreendeu o conceito de visão (leia [1]). Visões são
>> definidas com consultas e são utilizadas em consultas; funções recebem
>> parâmetros. A visão pode ser utilizada para restringir os dados a serem
>> obtidos ou mesmo encapsular uma consulta complexa. Você está pensando de
>> maneira procedural e não de maneira declarativa.
>>
>> [1] http://www.postgresql.org/docs/9.3/static/rules-views.html
>
> Pois é, acho que para o que eu quero a solução é mesmo função, view não tem o 
> recurso de receber paramento em tempo de execução como as funções.

Mateus, quando o Euler diz que a gente não entendeu algo, é bom pensar
se ele não tem razão.  Além do cara ser bom, é professor…

No caso, uma visão faz exatamente o que precisas, a menos que teu
ambiente de programação seja muito, mas muito estranho mesmo.
Simplesmente use uma variável ligada, que é a passagem de parâmetro
para SQL.  Algo como:

 SELECT  FROM  WHERE  
:;

Ela é uma função que devolve uma relação derivada, só não tem esse
nome.  Mas, se teu ambiente for estranho demais, sempre podes usar uma
função tradicional, que é bem mais chatinha.

Alguém me corrija se eu tiver falado bobagem, estou afastado da
programação há tanto tempo…


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

Re: [pgbr-geral] VIEWS com parâmetro

[Matheus Saraiva]

Em 05-02-2014 17:44, Euler Taveira escreveu:

On 05-02-2014 15:40, Matheus Saraiva wrote:

E se eu quisesse não escrever nenhum WHERE na linha que chama a VIEW?
Algo como:

CREATE VIEW funcionarios_ativos AS SELECT nome, salario FROM
funcionarios WHERE nome = (VALOR SERÁ PASSADO NA CHAMADA DA VIEW);

SELECT * FROM funcionarios_ativos (VALOR QUE SERÁ USADO NO WHERE
ENCAPSULADO);

Como ficaria?


Vejo que você não compreendeu o conceito de visão (leia [1]). Visões são
definidas com consultas e são utilizadas em consultas; funções recebem
parâmetros. A visão pode ser utilizada para restringir os dados a serem
obtidos ou mesmo encapsular uma consulta complexa. Você está pensando de
maneira procedural e não de maneira declarativa.


[1] http://www.postgresql.org/docs/9.3/static/rules-views.html


Pois é, acho que para o que eu quero a solução é mesmo função, view não 
tem o recurso de receber paramento em tempo de execução como as funções.

___
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 com parâmetro

[Euler Taveira]

On 05-02-2014 15:40, Matheus Saraiva wrote:
> E se eu quisesse não escrever nenhum WHERE na linha que chama a VIEW?
> Algo como:
> 
> CREATE VIEW funcionarios_ativos AS SELECT nome, salario FROM
> funcionarios WHERE nome = (VALOR SERÁ PASSADO NA CHAMADA DA VIEW);
> 
> SELECT * FROM funcionarios_ativos (VALOR QUE SERÁ USADO NO WHERE
> ENCAPSULADO);
> 
> Como ficaria?
>
Vejo que você não compreendeu o conceito de visão (leia [1]). Visões são
definidas com consultas e são utilizadas em consultas; funções recebem
parâmetros. A visão pode ser utilizada para restringir os dados a serem
obtidos ou mesmo encapsular uma consulta complexa. Você está pensando de
maneira procedural e não de maneira declarativa.


[1] http://www.postgresql.org/docs/9.3/static/rules-views.html


-- 
   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] VIEWS com parâmetro

[Daniel Cordeiro]

Em 05-02-2014 11:55, Matheus de Oliveira escreveu:
...
', uma vez que a view vai gerar todos os dados e só depois é que o 
planejador realizará a restrição através do cláusula WHERE e 
ordenações necessárias.




humm... Sua afirmação não está correta. Dada a view "teste" a seguinte 
consulta:


SELECT * FROM teste WHERE nome = 'matheus';

Passa por algumas transformações, primeiro:

SELECT * FROM (SELECT id_nome, nome FROM nomes) teste WHERE nome = 
'matheus';

EXECUTE nunca é minha primeira opção
Em seguida, o PostgreSQL "percebe" que não precisa da subquery e 
transforma a query acima em:


SELECT id_nome, nome FROM nomes AS teste WHERE teste.nome = 'matheus';

Resumindo, a view não vai gerar todos os dados, a consulta (acima) é 
que será executada no final (claro ainda tem o plano de execução, 
métodos de acesso, etc.).


Eu até diria que nesse exemplo específico a view me parece até mais 
adequada e mais fácil de manter do que a função.



Como eu falei no email que respondi para Euler: My bad :-(


Minha sugestão é criar uma função que realiza a consulta já
adicionando as restrições necessárias para a triagem inicial dos
dados desejados.

Ex (descartando índices, segurança da função, etc)*1*.

/CREATE TABLE lancamentos (id int, conta text, campo1 text,
campo2 text);//
//
//INSERT INTO lancamentos
VALUES(1,'Produtivo','valor1','valor2');//
//INSERT INTO lancamentos
VALUES(2,'Produtivo','valor1','valor2');//
//INSERT INTO lancamentos
VALUES(3,'Mecanica','valor1','valor2');//
//INSERT INTO lancamentos
VALUES(4,'Mecanica','valor1','valor2');//

//
//CREATE OR REPLACE FUNCTION sp_lancamentos(IN CODCONTA
varchar) RETURNS TABLE(i int, c1 text,c2 text, c text)//
//AS $$//
//
//BEGIN//
//RETURN QUERY SELECT id,conta,campo1,campo2 FROM
lancamentos WHERE conta = CODCONTA;//
//END;//
//$$//
//language 'plpgsql';/



OK. Realmente, para aceitar parâmetros da forma que o OP espera, é 
necessário sim uma função.


Eu só recomendaria, nesse caso especificamente, a usar uma função SQL 
ao invés de PL/pgSQL:


CREATE OR REPLACE FUNCTION sp_lancamentos(IN CODCONTA varchar)
RETURNS TABLE(i int, c1 text,c2 text, c text)
AS $$
SELECT id,conta,campo1,campo2 FROM lancamentos WHERE conta = 
CODCONTA;

$$
LANGUAGE SQL;

Para chamá-la:

SELECT * FROM sp_lancamentos('Produtivo');

(a chamada em si seria igual à PL/pgSQL, só quis exemplificar)]
Claro, usei o plpgsql por me basear em algo que já tinha, e o mesmo 
depende dos recursos além da sql.


Para uma function muito grande e com muitas variáveis para
substituição, vale a pena utilizar a cláusula EXECUTE no RETURN
QUERY (isso já me salvou de vários problemas em functions com mais
mais de 1500 linhas e código e dezenas de variáveis)*2*:
/

RETURN QUERY EXECUTE 'SELECT id,conta,campo1,campo2 FROM
lancamentos WHERE conta = $1' USING CODCONTA;//
/



Ah? Por quê? Eu particularmente tento evitar o EXECUTE ao menos que 
estritamente necessário. Lembre-se que ele não pode ser otimizado pelo 
PL/pgSQL para armazenar o plano de execução.


Eu também não. Mas neste meu caso, após o crescimento de dados em alguns 
clientes (alguns milhões de registros em dezenas de tabelas), o 
QueryPlan dentro da procedure passou a ser tratado de maneira totalmente 
diferente  se comparado à execução da mesma query já com os valores 
prefixados nas condicionais e subqueryes fora da procedure. 
Aparentemente, como o prepare acontece antes do conhecimento dos 
parâmetros na procedure, o planejador gerava um plano de execução mais 
custoso. (novamente, esta foi a minha impressão sobre o caso).


Estou falando da mesma consulta rodando em 5 horas dentro da procedure e 
7 segundos rodando fora. Inicialmente pensei que fosse a adoção do 
RETURN QUERY. Ao modificar a procedure fazendo o retorno com o EXECUTE, 
o tempo foi normalizado e o custo de operação dentro e fora da procedure 
ficou, de fato, irrelevante.





Lembrando que estas ações podem dificultar a análise de um
problema futuro, pois o EXPLAIN não vai detalhar o conteúdo
interno executado na função e nem nos logs.


+1. Otimizar funções é uma tarefa bem árdua. Só uma dica, a extensão 
auto_explain pode ajudar nessa tarefa. ;-)


Obrigado pela dica! Vou estudar a extensão para verificar sua adoção em 
nosso ambiente.


Atenciosamente

--
+--+
| Daniel Cordeiro de Morais Neto
| Diretor de TI - Portal de Cotações e-Compras
| Sócio-diretor ADM Soluções em Informática LTDA
| daniel.cordeiro(at)cotacoesecompras.com.br
| dmoraisn(at)gmail.com
| www.cotacoesecompras.com.br
| Fone: (083)8724-4440
| Gentoo User
| http://twitter.com/dmoraisn
+

Re: [pgbr-geral] VIEWS com parâmetro

[Matheus Saraiva]

Em 05-02-2014 17:02, Douglas Fabiano Specht escreveu:




Em 5 de fevereiro de 2014 16:40, Matheus Saraiva 
mailto:matheus.sara...@gmail.com>> escreveu:


Em 05-02-2014 12:54, Euler Taveira escreveu:

On 05-02-2014 11:32, Matheus Saraiva wrote:

Quero deixar a clausula where encapsulada na view e na
chamada da view
eu passaria apenas o nome 'matheus', 'paulo', 'joão', etc

E você pode deixar condições da cláusula WHERE encapsuladas na
VIEW. Por
exemplo:

CREATE VIEW funcionarios_ativos AS SELECT nome, salario FROM
funcionarios WHERE status = TRUE;

SELECT * FROM funcionarios_ativos WHERE nome = 'foo';

Ele apresentará somente funcionários cujo nome é 'foo' e que
estejam
"ativos". O que a visão faz é mesclar o SELECT que a definiu com o
SELECT na qual ela foi utilizada. Portanto, internamente temos uma
reescrita da consulta para:

SELECT nome, salario FROM funcionarios WHERE status = TRUE AND
nome = 'foo';

Observe que *somente* as colunas mencionadas na definição da
visão são
apresentadas.



E se eu quisesse não escrever nenhum WHERE na linha que chama a
VIEW? Algo como:


CREATE VIEW funcionarios_ativos AS SELECT nome, salario FROM
funcionarios WHERE nome = (VALOR SERÁ PASSADO NA CHAMADA DA VIEW);

SELECT * FROM funcionarios_ativos (VALOR QUE SERÁ USADO NO WHERE
ENCAPSULADO);

Como ficaria?

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br

https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Mateus
explique melhor por que vc precisa ser dessa maneira, pois diretamente 
na view nao é possivel, somente criando uma função para isso.


--

Douglas Fabiano Specht


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Quero fazer o que o Matheus Oliveira fez, porém, com VIEW. Meu objetivo 
com isso é minimizar o máximo possível o tamanho da linha ao chamar a 
view. Vi que isso pode ser feito com funções, mas trabalhar com VIEW é 
mais prático. Resumindo quero deixar tudo encapsulado sem ter que 
escrever clausula WHERE na linha de chamada da view. Quero apenas passar 
o nome da view e o valor que será usado no filtro where que está dentro 
da view. Igualmente como eu faria se fosse uma função: SELECT * FROM 
sp_teste('TESTANDO');.

Mas pelo que vejo, view não suporta isso. Sendo possível apenas com funçã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] VIEWS com parâmetro

[Douglas Fabiano Specht]

Em 5 de fevereiro de 2014 16:40, Matheus Saraiva
escreveu:

> Em 05-02-2014 12:54, Euler Taveira escreveu:
>
>  On 05-02-2014 11:32, Matheus Saraiva wrote:
>>
>>> Quero deixar a clausula where encapsulada na view e na chamada da view
>>> eu passaria apenas o nome 'matheus', 'paulo', 'joão', etc
>>>
>>>  E você pode deixar condições da cláusula WHERE encapsuladas na VIEW. Por
>> exemplo:
>>
>> CREATE VIEW funcionarios_ativos AS SELECT nome, salario FROM
>> funcionarios WHERE status = TRUE;
>>
>> SELECT * FROM funcionarios_ativos WHERE nome = 'foo';
>>
>> Ele apresentará somente funcionários cujo nome é 'foo' e que estejam
>> "ativos". O que a visão faz é mesclar o SELECT que a definiu com o
>> SELECT na qual ela foi utilizada. Portanto, internamente temos uma
>> reescrita da consulta para:
>>
>> SELECT nome, salario FROM funcionarios WHERE status = TRUE AND nome =
>> 'foo';
>>
>> Observe que *somente* as colunas mencionadas na definição da visão são
>> apresentadas.
>>
>>
>>
> E se eu quisesse não escrever nenhum WHERE na linha que chama a VIEW? Algo
> como:
>
>
> CREATE VIEW funcionarios_ativos AS SELECT nome, salario FROM
> funcionarios WHERE nome = (VALOR SERÁ PASSADO NA CHAMADA DA VIEW);
>
> SELECT * FROM funcionarios_ativos (VALOR QUE SERÁ USADO NO WHERE
> ENCAPSULADO);
>
> Como ficaria?
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>

Mateus
explique melhor por que vc precisa ser dessa maneira, pois diretamente na
view nao é possivel, somente criando uma função para isso.

-- 

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] VIEWS com parâmetro

[Matheus Saraiva]

Em 05-02-2014 12:55, Matheus de Oliveira escreveu:




2014-02-05 Daniel Cordeiro >:


Bom dia,

Em 05-02-2014 11:02, Rafael Fialho Corrêa escreveu:

Em 5 de fevereiro de 2014 11:55, Matheus Saraiva
mailto:matheus.sara...@gmail.com>>
escreveu:


Rafael Fialho

Não entendi o que vc quis dizer, o que preciso é que a
clausula WHERE receba um parâmetro. Como:

V = 'matheus'

WHERE nome = V

A variável V receberia o seu valor por parâmetro.


O que quero dizer é o seguinte:

CREATE OR REPLACE VIEW teste AS
  select
id_nome
, nome
  from
nomes;
GRANT ALL ON TABLE teste TO public;

"select * from teste where nome = 'matheus';"

Simples assim.. hehehe Isso que eu quis dizer.

Acredito que esta não seja uma opção tão 'performática', uma vez
que a view vai gerar todos os dados e só depois é que o planejador
realizará a restrição através do cláusula WHERE e ordenações
necessárias.


humm... Sua afirmação não está correta. Dada a view "teste" a seguinte 
consulta:


SELECT * FROM teste WHERE nome = 'matheus';

Passa por algumas transformações, primeiro:

SELECT * FROM (SELECT id_nome, nome FROM nomes) teste WHERE nome = 
'matheus';


Em seguida, o PostgreSQL "percebe" que não precisa da subquery e 
transforma a query acima em:


SELECT id_nome, nome FROM nomes AS teste WHERE teste.nome = 'matheus';

Resumindo, a view não vai gerar todos os dados, a consulta (acima) é 
que será executada no final (claro ainda tem o plano de execução, 
métodos de acesso, etc.).


Eu até diria que nesse exemplo específico a view me parece até mais 
adequada e mais fácil de manter do que a função.


Minha sugestão é criar uma função que realiza a consulta já
adicionando as restrições necessárias para a triagem inicial dos
dados desejados.

Ex (descartando índices, segurança da função, etc)*1*.

/CREATE TABLE lancamentos (id int, conta text, campo1 text,
campo2 text);//
//
//INSERT INTO lancamentos
VALUES(1,'Produtivo','valor1','valor2');//
//INSERT INTO lancamentos
VALUES(2,'Produtivo','valor1','valor2');//
//INSERT INTO lancamentos
VALUES(3,'Mecanica','valor1','valor2');//
//INSERT INTO lancamentos
VALUES(4,'Mecanica','valor1','valor2');//

//
//CREATE OR REPLACE FUNCTION sp_lancamentos(IN CODCONTA
varchar) RETURNS TABLE(i int, c1 text,c2 text, c text)//
//AS $$//
//
//BEGIN//
//RETURN QUERY SELECT id,conta,campo1,campo2 FROM
lancamentos WHERE conta = CODCONTA;//
//END;//
//$$//
//language 'plpgsql';/



OK. Realmente, para aceitar parâmetros da forma que o OP espera, é 
necessário sim uma função.


Eu só recomendaria, nesse caso especificamente, a usar uma função SQL 
ao invés de PL/pgSQL:


CREATE OR REPLACE FUNCTION sp_lancamentos(IN CODCONTA varchar)
RETURNS TABLE(i int, c1 text,c2 text, c text)
AS $$
SELECT id,conta,campo1,campo2 FROM lancamentos WHERE conta = 
CODCONTA;

$$
LANGUAGE SQL;

Para chamá-la:

SELECT * FROM sp_lancamentos('Produtivo');

(a chamada em si seria igual à PL/pgSQL, só quis exemplificar)

Para uma function muito grande e com muitas variáveis para
substituição, vale a pena utilizar a cláusula EXECUTE no RETURN
QUERY (isso já me salvou de vários problemas em functions com mais
mais de 1500 linhas e código e dezenas de variáveis)*2*:
/

RETURN QUERY EXECUTE 'SELECT id,conta,campo1,campo2 FROM
lancamentos WHERE conta = $1' USING CODCONTA;//
/



Ah? Por quê? Eu particularmente tento evitar o EXECUTE ao menos que 
estritamente necessário. Lembre-se que ele não pode ser otimizado pelo 
PL/pgSQL para armazenar o plano de execução.



Lembrando que estas ações podem dificultar a análise de um
problema futuro, pois o EXPLAIN não vai detalhar o conteúdo
interno executado na função e nem nos logs.


+1. Otimizar funções é uma tarefa bem árdua. Só uma dica, a extensão 
auto_explain pode ajudar nessa tarefa. ;-)


*1* -
http://www.postgresql.org/docs/9.3/static/plpgsql-declarations.html
*2* -
http://www.postgresql.org/docs/9.3/static/plpgsql-statements.html




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



Acho que essa opção do Matheus Oliveira seria bem o que estou 
procurando, pois como respondi ao Euler Taveira, não quero escrever 
nenhuma clausula WHERE na chamada da VIEW. A não ser que view também 
receba parâmetros deste m

Re: [pgbr-geral] pg_basebackup para fita

[Douglas Fabiano Specht]

Em 5 de fevereiro de 2014 16:28, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

>
> > Gostaria de saber se é viável e se tem como eu rodar um pg_basebackup e
> mandar direto para a fita (/dev/st0)?
>
> Sim sem problemas.
> O único inconveniente que vejo é que isso demora dependendo do tamanho,
> mas aí é caso a caso.
>
> [] s
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
nao seria melhor vc colocar para fazer o bckup um uma partição do disco, e
ter um shell script que copie ele para a fita?

-- 

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] VIEWS com parâmetro

[Matheus Saraiva]

Em 05-02-2014 12:54, Euler Taveira escreveu:

On 05-02-2014 11:32, Matheus Saraiva wrote:

Quero deixar a clausula where encapsulada na view e na chamada da view
eu passaria apenas o nome 'matheus', 'paulo', 'joão', etc


E você pode deixar condições da cláusula WHERE encapsuladas na VIEW. Por
exemplo:

CREATE VIEW funcionarios_ativos AS SELECT nome, salario FROM
funcionarios WHERE status = TRUE;

SELECT * FROM funcionarios_ativos WHERE nome = 'foo';

Ele apresentará somente funcionários cujo nome é 'foo' e que estejam
"ativos". O que a visão faz é mesclar o SELECT que a definiu com o
SELECT na qual ela foi utilizada. Portanto, internamente temos uma
reescrita da consulta para:

SELECT nome, salario FROM funcionarios WHERE status = TRUE AND nome = 'foo';

Observe que *somente* as colunas mencionadas na definição da visão são
apresentadas.




E se eu quisesse não escrever nenhum WHERE na linha que chama a VIEW? 
Algo como:


CREATE VIEW funcionarios_ativos AS SELECT nome, salario FROM
funcionarios WHERE nome = (VALOR SERÁ PASSADO NA CHAMADA DA VIEW);

SELECT * FROM funcionarios_ativos (VALOR QUE SERÁ USADO NO WHERE ENCAPSULADO);

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

Re: [pgbr-geral] pg_basebackup para fita

[Flavio Henrique Araque Gurgel]

> Gostaria de saber se é viável e se tem como eu rodar um pg_basebackup e
mandar direto para a fita (/dev/st0)?

Sim sem problemas.
O único inconveniente que vejo é que isso demora dependendo do tamanho, mas
aí é caso a caso.

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

Re: [pgbr-geral] Como resolver alta demanda de conexoes

[Guimarães Faria Corcete DUTRA , Leandro]

2014-02-05 Cicero Neto :
> PARA OS DBAS jr ou candidato há ..

Para quem não respeita a netiqueta, maiúsculas são grito e não são bem vistas.

Também é bom saber escrever português.  Há candidados a DBA júnior,
mas não se pode confundir o verbo haver (há) com a partícula ‘a’.


> ÍNDICE LOCAL É QUANDO A INDEXAÇÃO É FÍSICA

E o que seria indexação não física?  Lógica?  Espiritual?  Indexação,
em SGBDs, é um conceito exclusivamente físico.


> OU SEJA DIRETO NA TABELA, COMO UMA PK

Chaves são conceitos lógicos, e índices físicos; mas os índices
associados a chaves não diferem em nada de outros índices, nem mesmo
se forem chaves primárias.  Todo índice ou chave é obviamente ligado a
uma tabela, mas é uma estrutura separada.


> ÍNDICES ORBITAIS COM O PRÓPRIO NOME DIZ, ORBITAM A TABELA

Isso não faz sentido.  Nunca vi esse conceito em SGBD nenhum, muito
menos na teoria.


> SÃO TABELAS DE ÍNDICES AUXILIARES

Índices e tabelas não se confundem: não há nem ‘tabelas de índices’,
nem ‘índices auxiliares’.  Não que eu me lembre.


> COMO SE FOSSE O ÍNDICE DE UM LIVRO.

Entendo um pouco de livros, e um pouco de SGBDs.  Os dois têm em comum
conterem informações, mas certamente não muito mais do que isso.  Essa
tua símile não carrega informação nenhuma.


> ISSO
> GERA I/O (vocês sabem o que é I/O né?) no disco, sobrecarrega o BUFFER .

Falaste, falaste, e não disseste nada.


> SOU PROFISSIONAL DE TI A 30 ANOS, DBA SR A 15.

Ai de teus usuários.


> leio muita coisa postada aqui

E, pelo jeito, não entendeste nada.

Tenho que te pedir para não responder mais nenhuma pergunta técnica,
por óbvia falta de capacidade de comunicação, provavelmente de
conhecimento básico também.  Embora a gente se preocupe em corrigir,
isso desperdiça tempo de todos e, em especial, confunde os novatos.  E
o que dizes nem são os enganos comuns de novatos, que acabamos
ensinando (e até aprendendo) algo, ao corrigir.  Limite‐se a
perguntar, por favor, até aprender mais.

Uma dica: decorar regras para aplicar sem entender não é conhecimento,
é decoreba.  Essas regras impedem que a experiência gere conhecimento,
abandone‐as e estude os conceitos básicos.  Só depois volte a se
preocupar com produtos e tecnologia.


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

[pgbr-geral] pg_basebackup para fita

[Jean Pereira]

Boa tarde,

Gostaria de saber se é viável e se tem como eu rodar um pg_basebackup e 
mandar direto para a fita (/dev/st0)?


Abraç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] Vaga Analista de Suporte DBA

[Bruno Silva]

2014-02-03 jorge :
> Temos atualmente 2 datacenters  e em um deles Exadata e Exalogic
> (parte da Oracle), porem, o DBA em questão não tem foco nesta tecnologia a
> curto prazo (por isso vai precisar saber Oracle);
> Só usamos servidores Linux (varias distribuições);
> Atualmente estamos em 4 DBAs, porem, precisamos de mais;
Achei interessante, mas queria entender:
1 - A vaga é para Oracle ou Postgres?
2 - Como assim não tem foco a curto prazo?
___
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 com parâmetro

[Daniel Cordeiro]

Em 05-02-2014 12:10, Euler Taveira escreveu:

On 05-02-2014 11:41, Daniel Cordeiro wrote:

Acredito que esta não seja uma opção tão 'performática', uma vez que a
view vai gerar todos os dados e só depois é que o planejador realizará a
restrição através do cláusula WHERE e ordenações necessárias.


Você está equivocado. Nenhum dado é gerado por ser uma visão. Há uma
etapa antes do planejamento que se chama reescrita. Nesta etapa, as
visões são mescladas com a consulta informada e somente depois a árvore
de consulta é passada para o planejador escolher o plano.
Obrigado pela correção Euler. Na ânsia de explicar uma forma de executar 
o que se tinha interesse escrevi sem nem pensar na reescrita feita pelo 
planejador antes da execução. Serei mais cuidadoso nas próximas!


Acontece que minha realidade para a consulta que impulsionou a escolha 
por uma procedure ao invés de uma visão é bem diferente da exposta no 
início deste tópico. Minha consulta possui diversas subqueryes com 
definições de parâmetros  e cálculos  que não puderam ser 
solucionados/otimizados com uso de CTEs ou views (e se tornou 
impraticável para o momento a reescrita do modelo de negócio do banco). 
E não apenas encapsular uma única condição.


Claro, sempre existe uma forma melhor de se fazer, o limite neste 
contexto esta no meu 'universo conhecido' ;-P.

O tempo de reescrita não é algo crítico (pelo menos nunca vi relatos).
Além disso, é ingenuidade pensar que a execução de funções não tem custo
inicial. Eu só usaria funções se precisasse de algo procedural (se bem
que dá para fazer várias coisas procedurais com SQL :-).




--
+--+
| Daniel Cordeiro de Morais Neto
| Diretor de TI - Portal de Cotações e-Compras
| Sócio-diretor ADM Soluções em Informática LTDA
| daniel.cordeiro(at)cotacoesecompras.com.br
| dmoraisn(at)gmail.com
| www.cotacoesecompras.com.br
| Fone: (083)8724-4440
| Gentoo User
| http://twitter.com/dmoraisn
+--+

___
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 resolver alta demanda de conexoes

[Euler Taveira]

On 05-02-2014 13:27, Cicero Neto wrote:
> *PARA OS DBAS jr* ou candidato há ..
> 
s/há/a/

> ÍNDICE LOCAL É QUANDO A INDEXAÇÃO É FÍSICA, OU SEJA DIRETO NA TABELA, COMO
> UMA PK, ÍNDICES ORBITAIS COM O PRÓPRIO NOME DIZ, ORBITAM A TABELA ,
> SÃO TABELAS DE ÍNDICES AUXILIARES COMO SE FOSSE O ÍNDICE DE UM LIVRO. ISSO
> GERA I/O (vocês sabem o que é I/O né?) no disco, sobrecarrega o BUFFER .
> 
[não precisa gritar...]

De qual literatura você tirou a nomenclatura "índice orbital"? Nos
principais livros de banco de dados (Ramakrishnan, Ullman, Navathe,
Silberschatz, para citar alguns) *não* há uso de tal termo. Nem mesmo
uma busca no pai dos burros (google) retornou algo conclusivo. Portanto,
não me admira a *grande* maioria desta lista não conhecer tal termo.


-- 
   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] Vaga Analista de Suporte DBA

[Guimarães Faria Corcete DUTRA , Leandro]

2014-02-05 Cicero Neto :
>
> …é para DBA PostGres/Oracle, ou Oracle/PostGres ou só postgress?

PostgreSQL ou Postgres, não postgress nem PostGres.


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

Re: [pgbr-geral] Como resolver alta demanda de conexoes

[Rafael Fialho Corrêa]

Em 5 de fevereiro de 2014 14:27, Cicero Neto escreveu:

> *PARA OS DBAS jr* ou candidato há ..
>
> ÍNDICE LOCAL É QUANDO A INDEXAÇÃO É FÍSICA, OU SEJA DIRETO NA TABELA, COMO
> UMA PK, ÍNDICES ORBITAIS COM O PRÓPRIO NOME DIZ, ORBITAM A TABELA ,
> SÃO TABELAS DE ÍNDICES AUXILIARES COMO SE FOSSE O ÍNDICE DE UM LIVRO. ISSO
> GERA I/O (vocês sabem o que é I/O né?) no disco, sobrecarrega o BUFFER .
>
> SOU PROFISSIONAL DE TI A 30 ANOS, DBA SR A 15. leio muita coisa postada
> aqui q
>

Não vou debater sobre as tuas informações pra não gerar mais discussão.

E nada contra, Cícero, e com todo o respeito do mundo, mas respeito e
credibilidade não se conquistam impondo credenciais.

Na minha opinião, quem precisa adicionar isso a qualquer informação, faz
isso porque a própria informação não tem a acreditação ou argumentação
necessária.

Além disso, isso já fugiu do tópico. Desculpas por isso.

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

Re: [pgbr-geral] Como resolver alta demanda de conexoes

[Cicero Neto]

que fico pasmo

"pas.mo
*sm* (*lat spasmu*) *1* Assombro, espanto, grande admiração. *2*
Desfalecimento,
desmaio. *3 **Vet V tétano. **4 **Reg* (Sul e Centro) Contração espasmódica
dos músculos maxilares, por excessiva sede da rês. *adj V pasmado*."

Entenderam???


Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 5 de fevereiro de 2014 14:27, Cicero Neto escreveu:

> *PARA OS DBAS jr* ou candidato há ..
>
> ÍNDICE LOCAL É QUANDO A INDEXAÇÃO É FÍSICA, OU SEJA DIRETO NA TABELA, COMO
> UMA PK, ÍNDICES ORBITAIS COM O PRÓPRIO NOME DIZ, ORBITAM A TABELA ,
> SÃO TABELAS DE ÍNDICES AUXILIARES COMO SE FOSSE O ÍNDICE DE UM LIVRO. ISSO
> GERA I/O (vocês sabem o que é I/O né?) no disco, sobrecarrega o BUFFER .
>
> SOU PROFISSIONAL DE TI A 30 ANOS, DBA SR A 15. leio muita coisa postada
> aqui q
>
> Seja Livre!
> Use OpenSource!
> LineOn, Tecnologia da Informação!
> http://lineonti.wordpress.com
>
>
>
> Em 3 de fevereiro de 2014 11:54, Tiago Adami  escreveu:
>
> Em 3 de fevereiro de 2014 11:50, Guimarães Faria Corcete DUTRA,
>> Leandro  escreveu:
>> > 2014-02-03 Cicero Neto :
>> >> rever indices locais e orbitais
>> >
>> > Alguém já entendeu o que o Cícero quer dizer com isso?
>>
>> Estava redigindo uma pergunta à lista quando sua mensagem apareceu -
>> ao mesmo tempo que inúmeras páginas do Google estavam abertas. Por um
>> momento me senti emburrecido por não conhecer a diferença entre os
>> dois...
>>
>> 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
>>
>
>
___
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 resolver alta demanda de conexoes

[Cicero Neto]

*PARA OS DBAS jr* ou candidato há ..

ÍNDICE LOCAL É QUANDO A INDEXAÇÃO É FÍSICA, OU SEJA DIRETO NA TABELA, COMO
UMA PK, ÍNDICES ORBITAIS COM O PRÓPRIO NOME DIZ, ORBITAM A TABELA ,
SÃO TABELAS DE ÍNDICES AUXILIARES COMO SE FOSSE O ÍNDICE DE UM LIVRO. ISSO
GERA I/O (vocês sabem o que é I/O né?) no disco, sobrecarrega o BUFFER .

SOU PROFISSIONAL DE TI A 30 ANOS, DBA SR A 15. leio muita coisa postada
aqui q

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 3 de fevereiro de 2014 11:54, Tiago Adami  escreveu:

> Em 3 de fevereiro de 2014 11:50, Guimarães Faria Corcete DUTRA,
> Leandro  escreveu:
> > 2014-02-03 Cicero Neto :
> >> rever indices locais e orbitais
> >
> > Alguém já entendeu o que o Cícero quer dizer com isso?
>
> Estava redigindo uma pergunta à lista quando sua mensagem apareceu -
> ao mesmo tempo que inúmeras páginas do Google estavam abertas. Por um
> momento me senti emburrecido por não conhecer a diferença entre os
> dois...
>
> 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
>
___
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

[Cicero Neto]

Jorge, boa tarde.
Por favor, me responda. A vaga é para DBA PostGres/Oracle, ou
Oracle/PostGres ou só postgress?

Grato a atenção.

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 3 de fevereiro de 2014 17:16, jorge  escreveu:

>  Bom dia pessoal,
>
> Preciso de um DBA Jr. e um Pleno para trabalhar em São Jose dos
> Pinhais - PR (Centro).
>
> A vaga é para a maior empresa de rastreamento de veículos do Brasil
> (SASCAR).
>
> Obrigatoriamente independente do nível, deve saber usar o Linux e
> Postgresql.
>
> Obrigatório Oracle (porem o nível não é diferencial no momento).
>
> Benefícios: Plano de saúde e odontológico Bradesco integral sem
> desconto em folha, VR ou VA + PPR
>
> Horário padrão -> segunda a sexta das 08:00 as 18:00 (porem pode
> ser
> um pouco flexível na entrada e saída dependendo das necessidades do
> candidato)
>
> Salários de 4k a 5k (vai depender do nível)
>
> Obs:
> Temos atualmente 2 datacenters  e em um deles Exadata e Exalogic
> (parte da Oracle), porem, o DBA em questão não tem foco nesta tecnologia a
> curto prazo (por isso vai precisar saber Oracle);
> Só usamos servidores Linux (varias distribuições);
> Atualmente estamos em 4 DBAs, porem, precisamos de mais;
>
> Obrigatório ficar de plantão e fazer sobreaviso (porem, quanto
> melhor fazer a lição de casa, não é acionado e ganha mesmo assim);
>
> Minha opinião que já estou a 7 anos na empresa (programador -> DBA
> -> DBA/Coordenador):
>
> Quem quer aprender e crescer profissionalmente esse é o
> lugar. Tecnologia de ponta, muitas possibilidades de aprendizado e
> liberdade
> para melhoria de processos.
> Empresa em constante crescimento e passando por um momento
> muito bom referente a parte de tecnologia e inovação.
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Pacote Senha Invalido

[Enio]

Valeu pela dica Matheus, sem ela iria demorar mais a chegar no problema.


Em 5 de fevereiro de 2014 13:04, Matheus de Oliveira <
matioli.math...@gmail.com> escreveu:

>
> 2014-02-03 Enio :
>
> Consegui identificar o motivo deste retorno no Log é um bug do UNIDAC
>> utilizado no Delphi , vide:
>> http://www.devart.com/unidac/revision_history.html
>>
>>
>>
> Opa. Que bom que você conseguiu identificar o motivo.
>
> Parabéns.
>
> 2014-01-23 Matheus de Oliveira :
>
>>
>> [...] esse tipo de erro não irá abortar a operação, por isso você percebe
>> que o cliente continua conectado. Ou seja, se tudo está funcionando,
>> basicamente você vai ter que [...] atualizar o driver do seu cliente.
>>
>> [...]
>>
>> A verificação é simples, checa se o tamanho (buf.len) do pacote que
>> contém a senha é igual à string (buf.data) dentro dele. Basicamente esse
>> erro aconteceria se o pacote enviado contém um caractere 0 (0x00 ou '\0')
>> no meio do pacote.
>>
>
>
>  [...]
>>
>
>>
> Pesquisando um pouco, verifiquei que houve casos desse com o UniDAC [2],
>> se não me engano (nem procurei pra saber) é um driver pra Delphi, certo?
>>
>>
>> [...]
>> [2] http://forums.devart.com/viewtopic.php?f=28&t=27742
>>
>
>
> 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
>
>


-- 
Enio Alcantara
eni...@gmail.com
msn: enio...@msn.com
My Blog: http://tecnologiapraque.blogspot.com/
Seja Livre use Linux
___
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 com parâmetro

[Euler Taveira]

On 05-02-2014 11:41, Daniel Cordeiro wrote:
> Acredito que esta não seja uma opção tão 'performática', uma vez que a
> view vai gerar todos os dados e só depois é que o planejador realizará a
> restrição através do cláusula WHERE e ordenações necessárias.
> 
Você está equivocado. Nenhum dado é gerado por ser uma visão. Há uma
etapa antes do planejamento que se chama reescrita. Nesta etapa, as
visões são mescladas com a consulta informada e somente depois a árvore
de consulta é passada para o planejador escolher o plano.

O tempo de reescrita não é algo crítico (pelo menos nunca vi relatos).
Além disso, é ingenuidade pensar que a execução de funções não tem custo
inicial. Eu só usaria funções se precisasse de algo procedural (se bem
que dá para fazer várias coisas procedurais com 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] Pacote Senha Invalido

[Matheus de Oliveira]

2014-02-03 Enio :

> Consegui identificar o motivo deste retorno no Log é um bug do UNIDAC
> utilizado no Delphi , vide:
> http://www.devart.com/unidac/revision_history.html
>
>
>
Opa. Que bom que você conseguiu identificar o motivo.

Parabéns.

2014-01-23 Matheus de Oliveira :

>
> [...] esse tipo de erro não irá abortar a operação, por isso você percebe
> que o cliente continua conectado. Ou seja, se tudo está funcionando,
> basicamente você vai ter que [...] atualizar o driver do seu cliente.
>
> [...]
>
> A verificação é simples, checa se o tamanho (buf.len) do pacote que contém
> a senha é igual à string (buf.data) dentro dele. Basicamente esse erro
> aconteceria se o pacote enviado contém um caractere 0 (0x00 ou '\0') no
> meio do pacote.
>


 [...]
>

>
Pesquisando um pouco, verifiquei que houve casos desse com o UniDAC [2], se
> não me engano (nem procurei pra saber) é um driver pra Delphi, certo?
>
>
> [...]
> [2] http://forums.devart.com/viewtopic.php?f=28&t=27742
>


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

Re: [pgbr-geral] VIEWS com parâmetro

[Matheus de Oliveira]

2014-02-05 Daniel Cordeiro :

>  Bom dia,
>
> Em 05-02-2014 11:02, Rafael Fialho Corrêa escreveu:
>
>  Em 5 de fevereiro de 2014 11:55, Matheus Saraiva <
> matheus.sara...@gmail.com> escreveu:
>
>>
>> Rafael Fialho
>>
>> Não entendi o que vc quis dizer, o que preciso é que a clausula WHERE
>> receba um parâmetro. Como:
>>
>> V = 'matheus'
>>
>> WHERE nome = V
>>
>> A variável V receberia o seu valor por parâmetro.
>>
>
>  O que quero dizer é o seguinte:
>
>  CREATE OR REPLACE VIEW teste AS
>   select
> id_nome
> , nome
>   from
> nomes;
> GRANT ALL ON TABLE teste TO public;
>
>  "select * from teste where nome = 'matheus';"
>
>  Simples assim.. hehehe Isso que eu quis dizer.
>
> Acredito que esta não seja uma opção tão 'performática', uma vez que a
> view vai gerar todos os dados e só depois é que o planejador realizará a
> restrição através do cláusula WHERE e ordenações necessárias.
>
>
humm... Sua afirmação não está correta. Dada a view "teste" a seguinte
consulta:

SELECT * FROM teste WHERE nome = 'matheus';

Passa por algumas transformações, primeiro:

SELECT * FROM (SELECT id_nome, nome FROM nomes) teste WHERE nome =
'matheus';

Em seguida, o PostgreSQL "percebe" que não precisa da subquery e transforma
a query acima em:

SELECT id_nome, nome FROM nomes AS teste WHERE teste.nome = 'matheus';

Resumindo, a view não vai gerar todos os dados, a consulta (acima) é que
será executada no final (claro ainda tem o plano de execução, métodos de
acesso, etc.).

Eu até diria que nesse exemplo específico a view me parece até mais
adequada e mais fácil de manter do que a função.



> Minha sugestão é criar uma função que realiza a consulta já adicionando as
> restrições necessárias para a triagem inicial dos dados desejados.
>
> Ex (descartando índices, segurança da função, etc)*1*.
>
> *CREATE TABLE lancamentos (id int, conta text, campo1 text, campo2 text);*
>
> *INSERT INTO lancamentos VALUES(1,'Produtivo','valor1','valor2');*
> *INSERT INTO lancamentos VALUES(2,'Produtivo','valor1','valor2');*
> *INSERT INTO lancamentos VALUES(3,'Mecanica','valor1','valor2');*
> *INSERT INTO lancamentos VALUES(4,'Mecanica','valor1','valor2');*
>
> *  *
> *CREATE OR REPLACE FUNCTION sp_lancamentos(IN CODCONTA varchar) RETURNS
> TABLE(i int, c1 text,c2 text, c text)*
> *AS $$*
>
> *BEGIN*
> *RETURN QUERY SELECT id,conta,campo1,campo2 FROM lancamentos WHERE
> conta = CODCONTA;*
> *END;*
> *$$*
> *language 'plpgsql';*
>
>
>
OK. Realmente, para aceitar parâmetros da forma que o OP espera, é
necessário sim uma função.

Eu só recomendaria, nesse caso especificamente, a usar uma função SQL ao
invés de PL/pgSQL:

CREATE OR REPLACE FUNCTION sp_lancamentos(IN CODCONTA varchar)
RETURNS TABLE(i int, c1 text,c2 text, c text)
AS $$
SELECT id,conta,campo1,campo2 FROM lancamentos WHERE conta =
CODCONTA;
$$
LANGUAGE SQL;

Para chamá-la:

SELECT * FROM sp_lancamentos('Produtivo');

(a chamada em si seria igual à PL/pgSQL, só quis exemplificar)


> Para uma function  muito grande e com muitas variáveis para substituição,
> vale a pena utilizar a cláusula EXECUTE no RETURN QUERY (isso já me salvou
> de vários problemas em functions com mais mais de 1500 linhas e código e
> dezenas de variáveis)* 2*:
>
>
> *  RETURN QUERY EXECUTE 'SELECT id,conta,campo1,campo2 FROM
> lancamentos WHERE conta = $1' USING CODCONTA;*
> 
>
>
>
Ah? Por quê? Eu particularmente tento evitar o EXECUTE ao menos que
estritamente necessário. Lembre-se que ele não pode ser otimizado pelo
PL/pgSQL para armazenar o plano de execução.



> Lembrando que estas ações podem dificultar a análise de um problema
> futuro, pois o EXPLAIN não vai detalhar o conteúdo interno executado na
> função e nem nos logs.
>
>
+1. Otimizar funções é uma tarefa bem árdua. Só uma dica, a extensão
auto_explain pode ajudar nessa tarefa. ;-)



>  *1* - http://www.postgresql.org/docs/9.3/static/plpgsql-declarations.html
> *2* - http://www.postgresql.org/docs/9.3/static/plpgsql-statements.html
>
>
>
>
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

Re: [pgbr-geral] VIEWS com parâmetro

[Euler Taveira]

On 05-02-2014 11:32, Matheus Saraiva wrote:
> Quero deixar a clausula where encapsulada na view e na chamada da view
> eu passaria apenas o nome 'matheus', 'paulo', 'joão', etc
> 
E você pode deixar condições da cláusula WHERE encapsuladas na VIEW. Por
exemplo:

CREATE VIEW funcionarios_ativos AS SELECT nome, salario FROM
funcionarios WHERE status = TRUE;

SELECT * FROM funcionarios_ativos WHERE nome = 'foo';

Ele apresentará somente funcionários cujo nome é 'foo' e que estejam
"ativos". O que a visão faz é mesclar o SELECT que a definiu com o
SELECT na qual ela foi utilizada. Portanto, internamente temos uma
reescrita da consulta para:

SELECT nome, salario FROM funcionarios WHERE status = TRUE AND nome = 'foo';

Observe que *somente* as colunas mencionadas na definição da visão são
apresentadas.


-- 
   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] VIEWS com parâmetro

[Rafael Fialho Corrêa]

Em 5 de fevereiro de 2014 12:41, Daniel Cordeiro escreveu:

>  Bom dia,
>
> Em 05-02-2014 11:02, Rafael Fialho Corrêa escreveu:
>
>  Em 5 de fevereiro de 2014 11:55, Matheus Saraiva <
> matheus.sara...@gmail.com> escreveu:
>
>>
>> Rafael Fialho
>>
>> Não entendi o que vc quis dizer, o que preciso é que a clausula WHERE
>> receba um parâmetro. Como:
>>
>> V = 'matheus'
>>
>> WHERE nome = V
>>
>> A variável V receberia o seu valor por parâmetro.
>>
>
>  O que quero dizer é o seguinte:
>
>  CREATE OR REPLACE VIEW teste AS
>   select
> id_nome
> , nome
>   from
> nomes;
> GRANT ALL ON TABLE teste TO public;
>
>  "select * from teste where nome = 'matheus';"
>
>  Simples assim.. hehehe Isso que eu quis dizer.
>
> Acredito que esta não seja uma opção tão 'performática', uma vez que a
> view vai gerar todos os dados e só depois é que o planejador realizará a
> restrição através do cláusula WHERE e ordenações necessárias.
>

Já realizaste testes para confirmar esta tua teoria, Daniel?

Possuo views complexas em tabelas grandes e nunca tive problemas com
performance. Inclusive isto pode ser verificado com o explain, onde todos
os índices são utilizados no plano de execução.

Até concordo em parte com a questão da função, é uma boa opção, só que, na
minha opinião, isso "engessa" uma coisa que deveria ser muito mais simples.

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

Re: [pgbr-geral] VIEWS com parâmetro

[Daniel Cordeiro]

Bom dia,

Em 05-02-2014 11:02, Rafael Fialho Corrêa escreveu:
Em 5 de fevereiro de 2014 11:55, Matheus Saraiva 
mailto:matheus.sara...@gmail.com>> escreveu:



Rafael Fialho

Não entendi o que vc quis dizer, o que preciso é que a clausula
WHERE receba um parâmetro. Como:

V = 'matheus'

WHERE nome = V

A variável V receberia o seu valor por parâmetro.


O que quero dizer é o seguinte:

CREATE OR REPLACE VIEW teste AS
  select
id_nome
, nome
  from
nomes;
GRANT ALL ON TABLE teste TO public;

"select * from teste where nome = 'matheus';"

Simples assim.. hehehe Isso que eu quis dizer.
Acredito que esta não seja uma opção tão 'performática', uma vez que a 
view vai gerar todos os dados e só depois é que o planejador realizará a 
restrição através do cláusula WHERE e ordenações necessárias.


Minha sugestão é criar uma função que realiza a consulta já adicionando 
as restrições necessárias para a triagem inicial dos dados desejados.


Ex (descartando índices, segurança da função, etc)*1*.

   /CREATE TABLE lancamentos (id int, conta text, campo1 text, campo2
   text);//
   //
   //INSERT INTO lancamentos VALUES(1,'Produtivo','valor1','valor2');//
   //INSERT INTO lancamentos VALUES(2,'Produtivo','valor1','valor2');//
   //INSERT INTO lancamentos VALUES(3,'Mecanica','valor1','valor2');//
   //INSERT INTO lancamentos VALUES(4,'Mecanica','valor1','valor2');//
   
   //
   //CREATE OR REPLACE FUNCTION sp_lancamentos(IN CODCONTA varchar)
   RETURNS TABLE(i int, c1 text,c2 text, c text)//
   //AS $$//
   //
   //BEGIN//
   //RETURN QUERY SELECT id,conta,campo1,campo2 FROM
   lancamentos WHERE conta = CODCONTA;//
   //END;//
   //$$//
   //language 'plpgsql';/


Para uma function  muito grande e com muitas variáveis para 
substituição, vale a pena utilizar a cláusula EXECUTE no RETURN QUERY 
(isso já me salvou de vários problemas em functions com mais mais de 
1500 linhas e código e dezenas de variáveis)*2*:

/

RETURN QUERY EXECUTE 'SELECT id,conta,campo1,campo2 FROM 
lancamentos WHERE conta = $1' USING CODCONTA;//

/


Lembrando que estas ações podem dificultar a análise de um problema 
futuro, pois o EXPLAIN não vai detalhar o conteúdo interno executado na 
função e nem nos logs.


*1* - http://www.postgresql.org/docs/9.3/static/plpgsql-declarations.html
*2* - http://www.postgresql.org/docs/9.3/static/plpgsql-statements.html


Espero ter ajudado.


--
+--+
| Daniel Cordeiro de Morais Neto
| Diretor de TI - Portal de Cotações e-Compras
| Sócio-diretor ADM Soluções em Informática LTDA
| daniel.cordeiro(at)cotacoesecompras.com.br
| dmoraisn(at)gmail.com
| www.cotacoesecompras.com.br
| Fone: (083)8724-4440
| Gentoo User
| http://twitter.com/dmoraisn
+--+

___
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 com parâmetro

[Matheus Saraiva]

Em 05-02-2014 12:02, Rafael Fialho Corrêa escreveu:
Em 5 de fevereiro de 2014 11:55, Matheus Saraiva 
mailto:matheus.sara...@gmail.com>> escreveu:



Rafael Fialho

Não entendi o que vc quis dizer, o que preciso é que a clausula
WHERE receba um parâmetro. Como:

V = 'matheus'

WHERE nome = V

A variável V receberia o seu valor por parâmetro.


O que quero dizer é o seguinte:

CREATE OR REPLACE VIEW teste AS
  select
id_nome
, nome
  from
nomes;
GRANT ALL ON TABLE teste TO public;

"select * from teste where nome = 'matheus';"

Simples assim.. hehehe Isso que eu quis dizer.

[]'s


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


Quero deixar a clausula where encapsulada na view e na chamada da view 
eu passaria apenas o nome 'matheus', 'paulo', 'joão', etc
___
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 com parâmetro

[Rafael Fialho Corrêa]

Em 5 de fevereiro de 2014 11:55, Matheus Saraiva
escreveu:

>
> Rafael Fialho
>
> Não entendi o que vc quis dizer, o que preciso é que a clausula WHERE
> receba um parâmetro. Como:
>
> V = 'matheus'
>
> WHERE nome = V
>
> A variável V receberia o seu valor por parâmetro.
>

O que quero dizer é o seguinte:

CREATE OR REPLACE VIEW teste AS
  select
id_nome
, nome
  from
nomes;
GRANT ALL ON TABLE teste TO public;

"select * from teste where nome = 'matheus';"

Simples assim.. hehehe Isso que eu quis dizer.

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

Re: [pgbr-geral] VIEWS com parâmetro

[Matheus Saraiva]

Em 04-02-2014 16:47, Daniel Cordeiro escreveu:


Em 04-02-2014 15:16, Matheus Saraiva escreveu:
Como faço para criar uma view que receba um parâmetro que será usado 
na clausula


WHERE ?



Uma forma é encapsular sua consulta em uma function recebendo 
parâmetros e usando como returns TABLE.


--
+--+
| Daniel Cordeiro de Morais Neto
| Diretor de TI - Portal de Cotações e-Compras
| Sócio-diretor ADM Soluções em Informática LTDA
| daniel.cordeiro(at)cotacoesecompras.com.br
| dmoraisn(at)gmail.com
|www.cotacoesecompras.com.br
| Fone: (083)8724-4440
| Gentoo User
|http://twitter.com/dmoraisn
+--+


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


Rafael Fialho

Não entendi o que vc quis dizer, o que preciso é que a clausula WHERE 
receba um parâmetro. Como:


V = 'matheus'

WHERE nome = V

A variável V receberia o seu valor por parâmetro.

Daniel Cordeiro

Como ficaria isso? Tem como deixar um exemplo?

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

[pgbr-geral] Res: Re: drop views em campo [resolvido]

[fors...@forsell.com.br]

Em 4 de fevereiro de 2014 17:09, fors...@forsell.com.br  escreveu:

Boa tarde, 
 
Quero excluir views que estão em um campo de uma tabela.
 
como se fosse
 
drop view (select campo from tabela);
 
e excluir todas as views que contém no campo.
 
tem como?
 
Att,
 
Erlon




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





cara veja se te ajuda, achei no google e ajustei..


BEGIN TRANSACTION;
DO $$DECLARE r record;
 DECLARE s TEXT;
BEGIN
FOR r IN select
c.table_schema,c. table_name
from information_schema.tables t
inner join information_schema.columns c on c.table_catalog = t.table_catalog
and c.table_schema = t.table_schema and c.table_name = t.table_name
left join information_schema.key_column_usage u on c.table_catalog = u
table_catalog and c.table_schema = u.table_schema and c.table_name = u
table_name and c.column_name = u.column_name
where  t.table_type='VIEW' and c.table_schema not like '%pg%' and c
table_schema ='dah' C.COLUMN_NAME like 'hash%'
group by 1,2
LOOP
s := 'DROP VIEW ' ||  quote_ident(r.table_schema) || '.' ||
quote_ident(r.table_name) || ';';




EXECUTE s;


RAISE NOTICE 's = % ',s;


END LOOP;
END$$;
ROLLBACK TRANSACTION;


ajuste  alterando o schema, campo e faça numa tabela de teste


-- 



Douglas Fabiano Specht


>
Funcionou certinho douglas, obrigado... como ficou meu comando :


BEGIN TRANSACTION;
DO $$DECLARE r record;
 DECLARE s TEXT;
BEGIN
FOR r IN  select * from information_schema.tables where
table_name like '%busca%'
LOOP
s := 'DROP VIEW ' ||  quote_ident(r.table_schema) || '.' ||
quote_ident(r.table_name) || ';';

EXECUTE s;
RAISE NOTICE 's = % ',s;


END LOOP;
END$$;
commit TRANSACTION;

eu tinha views geradas no banco de dados já com o filtro, isso agiliza puxar os 
dados para o sistema, e como são muitos dados, se 2 usuários fizessem o filtro 
quase ao mesmo tempo, puxava os dados que o ultimo filtrou, assim fiz views que 
tinham um prefixo + nome do usuario,,, para eu poder excluir elas, em cada 
cliente era diferente, com esse comando, filtrando pelo prefixo consigo fazer 
um comando que exclua em qualquer cliente.___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] [OFF] Tradução Manual PostGIS

[George Silva]

Pessoal, estamos fazendo um esforço da comunidade para podermos traduzir a
documentação oficial do PostGIS para diversas línguas. Entre estas línguas,
estão o PT-BR.

O projeto está hospedado no Transifex e qualquer um pode ajudar na
tradução. Basta fazer uma conta no site e ele tem uma tela que te ajuda a
rastrear o que precisa ser traduzido com interface para o preenchimento da
versão traduzida.

https://www.transifex.com/projects/p/postgis-1/

Vamos fazer um esforço para dar uma mão na tradução dessa documentação, já
que é um projeto amplamente utilizado pelas comunidades em questão.

Peço desculpas antecipadamente pelo cross-post e pelo off, mas quem tiver
afim de ajudar, só dar um grito.

-- 
George R. C. Silva
SIGMA Consultoria

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