Re: [pgbr-geral] Query - Construção - PostgreSQL 9.2

2016-01-22 Thread Flavio Henrique Araque Gurgel 

Já resolvi o problema... O Rafael aqui da Lista deu uma ajuda também!

Lucas.


Acabei achando o assunto original, vi que o Rafael sugeriu que fizesse 
um analyze no seu banco de dados. Foi isso que te resolveu o problema?


[]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] wrap for postgres

2016-01-22 Thread Dickson S. Guedes 
Em 21 de janeiro de 2016 22:24, Douglas Fabiano Specht
 escreveu:
> boa noite pessoal,
> como vamos ter algumas funções no banco de dados, como podemos restringir a
> visualização dos fontes das funções?
> encontrei algumas pagas mas queria algo open, ou nativo

A dica do Osvaldo é muito bem vinda, como não houveram outras
respostas e talvez você não queira fazer em C, podem haver outras
alternativas então vou fazer um adendo:

Primeiramente vamos partir das premissas que, seja qual for a
linguagem ou o método que você aplicar, não estarás seguro totalmente
e que se alguém está "furtando" seu código ou ideias dele há ai um
outro problema, pois,  se alguém realmente quiser pegar o conteúdo da
sua função ele vai dar um jeito de fazê-lo. Restringir o acesso em
termos de permissões também é complicado porque o usuário tem acesso
ao conteúdo da função via catálogo, claro. Com um pouco de coragem e
conhecimento seria possível burlar mas não para ambiente critico ou de
produção, apenas para caráter de estudo e conhecimento e ainda assim
com resultados imprevisíveis, podendo, inclusive, quebrar o
funcionamento de aplicações de monitoramento ou de administração.

Mas nada impede de você dificultar este acesso para que pelo menos os
usuários mais comuns ou mal intencionados tenham alguns níveis de
dificuldade.

Vamos lá, você não especificou em qual linguagem suas funções estão
escritas então eu vou divagar aqui sobre três possibilidades, sendo
que as duas primeiras seria você escrever bibliotecas em Perl ou em
Python, e elas estariam instaladas no S.O. e seriam acessíveis a
partir do Postgres via linguagens procedurais como PL/Perl [1] e
PL/Python [2] respectivamente. Em outras palavras as funções no banco
seriam "wrappers" em uma camada que chamariam as funções dentro das
libs que estariam em outra camada, como por exemplo: na PL você
poderia ter uma chamada que lê um registro de funcionário e passa ele
para um modulo Python externo que calcula o salário, um leitor curioso
pode ate ler sua função e ver "ah ele pega o João e calcula o salario
dele" mas não vai saber "o como é feito isso", ainda no caso do
Python, ele compila os arquivos .py para .pyc o que daria uma camada a
mais de ofuscação.

Pense nesse modelo como as aplicações web fazem com os navegadores,
uma parte do código no navegador outra parte no backend e neste ponto
alguns podem falar, "ah mas no Javascript tem como ofuscar o código",
pois bem, o Postgres tem também a PL/V8, e aqui teríamos a terceira
possibilidade que é escrever a PL em Javascript e então utilizar
alguma biblioteca existente no ecosistema do Javascript para ofuscação
de código.

Por conta dessa necessidade já houve casos propostos [3] na lista de
desenvolvedores do Postgres, então dê uma olhada para entender o
porquê isso não foi para frente ainda.

Mesmo com tudo isso é importante deixar bem claro que ofuscar código
não é proteger código pois, afinal, o brilho do Sol até ofusca as
estrelas durante o dia, mas elas ainda estão lá.


[1] http://www.postgresql.org/docs/current/static/plperl.html
[2] http://www.postgresql.org/docs/current/static/plpython.html
[3] 
http://www.postgresql.org/message-id/162867790801280451y5ca29f00i1a55e8673ba8...@mail.gmail.com


[]s
-- 
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://github.com/guedes - http://guedesoft.net
http://www.postgresql.org.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PgDay Curitiba - Março de 2016

2016-01-22 Thread ChIcO 
Em 21 de janeiro de 2016 11:30, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

> On 18-01-2016 16:25, ChIcO wrote:
> > Boa tarde pessoal,
> >
> > O site do PgDay Curitiba esta oficialmente no ar em
> > www.pgdaycuritiba.pr.gov.br .
> >
>
> Seria interessante na página principal colocar a data/hora do evento
>

Vou atualizar o site com o dia.

>
> > Neste momento estamos recebendo as inscrições de palestrantes até o dia
> > _*05 de fevereiro de 2016*_.
> >
>
> Ótimo!
>

Fica melhor para todo mundo, depois de aprovado aqui achei que seria mais
tranquilo alterar e deu certo.

>
> > Lembrando:
> > *Data*
> > 03 de março de 2016
> > *Horário*
> > Das 08:00 às 11:30 e das 13:30 às 18:00
> > *Local*
> > Celepar - Companhia de Tecnologia da Informação e Comunicação do Paraná
> > Rua Mateus Leme, 1561 - Bom Retiro
> > 80520-174 - *Curitiba* - PR - (41) 3200-5000
> >
>
> Tomei a liberdade e adicionei ao Wiki internacional [1]
>

Muito obrigado, não sabia para quem pedir para adicionar aos eventos
futuros.

>
> > Gostaria da presença do pessoal aqui da comunidade.
> >
>
> Ainda não tenho 100% de certeza mas estou me organizando para estar
> presente.
>
>
Seria uma honra a sua presença. Para mim o grande nome hoje em dia do
PostgreSQL BR.


> Att,
>
>
>

Abraços,
Francisco Summa
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Query - Construção - PostgreSQL 9.2

2016-01-22 Thread Rafael Fialho 
Em 22 de janeiro de 2016 06:35, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> Já resolvi o problema... O Rafael aqui da Lista deu uma ajuda também!
>>
>> Lucas.
>>
>
> Acabei achando o assunto original, vi que o Rafael sugeriu que fizesse um
> analyze no seu banco de dados. Foi isso que te resolveu o problema?
>

Na verdade ele precisava de rotinas que o ajudassem a diminuir a latência
do seu servidor, e fez isso otimizando o modelo de dados.
Pra isso foi feita uma nova tabela, via copy, e uma função pra auxiliar no
preenchimento de um número de "rótulo" pros registros.

[]'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] Query - Construção - PostgreSQL 9.2

2016-01-22 Thread Flavio Henrique Araque Gurgel 

Em 22 de janeiro de 2016 06:35, Flavio Henrique Araque Gurgel
mailto:fha...@gmail.com>> escreveu:

Já resolvi o problema... O Rafael aqui da Lista deu uma ajuda
também!

Lucas.


Acabei achando o assunto original, vi que o Rafael sugeriu que
fizesse um analyze no seu banco de dados. Foi isso que te resolveu o
problema?


Na verdade ele precisava de rotinas que o ajudassem a diminuir a
latência do seu servidor, e fez isso otimizando o modelo de dados.
Pra isso foi feita uma nova tabela, via copy, e uma função pra auxiliar
no preenchimento de um número de "rótulo" pros registros.


É uma pena que essa discussão rica não tenha passado aqui pela lista.
Ou pode ser que eu tenha perdido algo...

[]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] Query - Construção - PostgreSQL 9.2

2016-01-22 Thread Rafael Fialho 
Em 22 de janeiro de 2016 10:14, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> Em 22 de janeiro de 2016 06:35, Flavio Henrique Araque Gurgel
>> mailto:fha...@gmail.com>> escreveu:
>>
>> Já resolvi o problema... O Rafael aqui da Lista deu uma ajuda
>> também!
>>
>> Lucas.
>>
>>
>> Acabei achando o assunto original, vi que o Rafael sugeriu que
>> fizesse um analyze no seu banco de dados. Foi isso que te resolveu o
>> problema?
>>
>>
>> Na verdade ele precisava de rotinas que o ajudassem a diminuir a
>> latência do seu servidor, e fez isso otimizando o modelo de dados.
>> Pra isso foi feita uma nova tabela, via copy, e uma função pra auxiliar
>> no preenchimento de um número de "rótulo" pros registros.
>>
>
> É uma pena que essa discussão rica não tenha passado aqui pela lista.
> Ou pode ser que eu tenha perdido algo...


Acredito que sim, o colega mandou dois e-mails, o outro que tinha mais
detalhes, mas a solução não encontra-se, de certa forma, nele, só o caminho
pra ela. Acho que as dúvidas também não ficaram muito claras.. Fui atrás
por private porque realmente não tinha entendido quase nada.

[]'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] wrap for postgres

2016-01-22 Thread Douglas Fabiano Specht 
Em 22 de janeiro de 2016 09:13, Dickson S. Guedes 
escreveu:

> Em 21 de janeiro de 2016 22:24, Douglas Fabiano Specht
>  escreveu:
> > boa noite pessoal,
> > como vamos ter algumas funções no banco de dados, como podemos
> restringir a
> > visualização dos fontes das funções?
> > encontrei algumas pagas mas queria algo open, ou nativo
>
> A dica do Osvaldo é muito bem vinda, como não houveram outras
> respostas e talvez você não queira fazer em C, podem haver outras
> alternativas então vou fazer um adendo:
>
> Primeiramente vamos partir das premissas que, seja qual for a
> linguagem ou o método que você aplicar, não estarás seguro totalmente
> e que se alguém está "furtando" seu código ou ideias dele há ai um
> outro problema, pois,  se alguém realmente quiser pegar o conteúdo da
> sua função ele vai dar um jeito de fazê-lo. Restringir o acesso em
> termos de permissões também é complicado porque o usuário tem acesso
> ao conteúdo da função via catálogo, claro. Com um pouco de coragem e
> conhecimento seria possível burlar mas não para ambiente critico ou de
> produção, apenas para caráter de estudo e conhecimento e ainda assim
> com resultados imprevisíveis, podendo, inclusive, quebrar o
> funcionamento de aplicações de monitoramento ou de administração.
>
> Mas nada impede de você dificultar este acesso para que pelo menos os
> usuários mais comuns ou mal intencionados tenham alguns níveis de
> dificuldade.
>
> Vamos lá, você não especificou em qual linguagem suas funções estão
> escritas então eu vou divagar aqui sobre três possibilidades, sendo
> que as duas primeiras seria você escrever bibliotecas em Perl ou em
> Python, e elas estariam instaladas no S.O. e seriam acessíveis a
> partir do Postgres via linguagens procedurais como PL/Perl [1] e
> PL/Python [2] respectivamente. Em outras palavras as funções no banco
> seriam "wrappers" em uma camada que chamariam as funções dentro das
> libs que estariam em outra camada, como por exemplo: na PL você
> poderia ter uma chamada que lê um registro de funcionário e passa ele
> para um modulo Python externo que calcula o salário, um leitor curioso
> pode ate ler sua função e ver "ah ele pega o João e calcula o salario
> dele" mas não vai saber "o como é feito isso", ainda no caso do
> Python, ele compila os arquivos .py para .pyc o que daria uma camada a
> mais de ofuscação.
>
> Pense nesse modelo como as aplicações web fazem com os navegadores,
> uma parte do código no navegador outra parte no backend e neste ponto
> alguns podem falar, "ah mas no Javascript tem como ofuscar o código",
> pois bem, o Postgres tem também a PL/V8, e aqui teríamos a terceira
> possibilidade que é escrever a PL em Javascript e então utilizar
> alguma biblioteca existente no ecosistema do Javascript para ofuscação
> de código.
>
> Por conta dessa necessidade já houve casos propostos [3] na lista de
> desenvolvedores do Postgres, então dê uma olhada para entender o
> porquê isso não foi para frente ainda.
>
> Mesmo com tudo isso é importante deixar bem claro que ofuscar código
> não é proteger código pois, afinal, o brilho do Sol até ofusca as
> estrelas durante o dia, mas elas ainda estão lá.
>
>
> [1] http://www.postgresql.org/docs/current/static/plperl.html
> [2] http://www.postgresql.org/docs/current/static/plpython.html
> [3]
> http://www.postgresql.org/message-id/162867790801280451y5ca29f00i1a55e8673ba8...@mail.gmail.com
>
>
> []s
> --
> Dickson S. Guedes
> mail/xmpp: gue...@guedesoft.net - skype: guediz
> http://github.com/guedes - http://guedesoft.net
> http://www.postgresql.org.br
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


bom dia,
eu pensei em pl/pgsql, pois ele tem alguma compatibilidade com o oracle, e
as funções poderia aproveitar uma parte.

-- 

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] Query - Construção - PostgreSQL 9.2

2016-01-22 Thread Flavio Henrique Araque Gurgel 

É uma pena que essa discussão rica não tenha passado aqui pela lista.
Ou pode ser que eu tenha perdido algo...


Acredito que sim, o colega mandou dois e-mails, o outro que tinha mais
detalhes, mas a solução não encontra-se, de certa forma, nele, só o
caminho pra ela. Acho que as dúvidas também não ficaram muito claras..
Fui atrás por private porque realmente não tinha entendido quase nada.


Como eu havia dito, é uma pena, muita informação rica ficou apenas entre 
vocês dois. Se os esclarecimentos tivessem corrigo em público, mais 
pessoas poderiam ajudar e a ajuda toda beneficia a todos.


Mas enfim, é vosso direito fazer assim.

[]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] Query - Construção - PostgreSQL 9.2

2016-01-22 Thread Rafael Fialho 
Em 22 de janeiro de 2016 11:27, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> É uma pena que essa discussão rica não tenha passado aqui pela lista.
>> Ou pode ser que eu tenha perdido algo...
>>
>>
>> Acredito que sim, o colega mandou dois e-mails, o outro que tinha mais
>> detalhes, mas a solução não encontra-se, de certa forma, nele, só o
>> caminho pra ela. Acho que as dúvidas também não ficaram muito claras..
>> Fui atrás por private porque realmente não tinha entendido quase nada.
>>
>
> Como eu havia dito, é uma pena, muita informação rica ficou apenas entre
> vocês dois. Se os esclarecimentos tivessem corrigo em público, mais pessoas
> poderiam ajudar e a ajuda toda beneficia a todos.
>
> Mas enfim, é vosso direito fazer assim.


Claro, concordo plenamente! Porém, o assunto estava bem confuso e o colega
precisava de ajuda urgente.
Fique tranquilo, Flávio, ele ainda está trabalhando na solução, acredito eu.
Tenho certeza que, ao chegar nela, ele dividirá suas experiências por aqui.
;)

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