Em 20 de abril de 2017 14:17, escreveu:
> Olha o dono da empresa que teve esse problema tentou entrar em contato com
> o cara que fez, era de fora, mas ele percebeu que o cara ia pegar a grana e
> ja era...
> As vezes um zé mané na web, pega esse virus em sites que ensinam usar
> esses virus, e m
Apenas para deixar meu humilde caso, assim como o Adami, porém sem maiores
detalhes.
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
Em 28 de junho de 2016 11:07, Fábio Telles Rodriguez escreveu:
> Senhores, estou preparando uma palestra sobre PostgreSQL e gostaria de
> pedir uma mãozinha do pessoal aqui... Quais os maiores mitos que vocês
> conhecem sobre PostgreSQL?
>
Como vários já disseram...Falta de Suporte.
>
>
> > Como a ocorrência é relativamente grande (10 em 50), achei que seria
> comum a mais gente.
>
> Você pode esperar para ver se aparece mais alguém, mas acho
> improvável. Melhor investigar a causa, fornecendo as informações que
> o Gurgel pediu e eu reforcei.
>
Conforme o Leandro disse "cor
O problema não é com o componente.
Mesmo usando pgAdmin ou psql a lentidão continua. Você está usando uma
solução cliente-servidor pela internet, você vai precisar de um link
dedicado pra melhorar isso, ou:
1) Utilizar 3 camadas, em Delphi(DataSnap), para que o banco de dados fique
do lado do serv
Legal. Curti.
Em 24 de fevereiro de 2016 21:29, Franklin Anderson de Oliveira Souza <
frankli...@gmail.com> escreveu:
> Maravilha muito bom essa iniciativa, parabéns !!!
> Em 24 de fev de 2016 7:56 PM, "Fabrízio de Royes Mello" <
> fabri...@timbira.com.br> escreveu:
>
>> Pessoal,
>>
>> De acordo
> Você tentou fazer um EXPLAIN ANALYZE do seu INSERT?
> Normalmente todas as execuções de função aparecem.
É isso mesmo. Obrigado Flavio.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/lis
Boa tarde,
Existe alguma de se fazer um "tracert", em funções chamadas através de um DML.
Por exemplo: INSERT INTO table A VALUES (1);
Na tabela A existe uma trigger que insere alguma informação na tabela
B, a tabela B tem uma trigger after insert/update/delete que insere
alguma informação na ta
Bom dia pessoal,
Existe alguma diferença relevante de deixar o parâmetro timezone como
"Brazil/East" ou como ""Etc/GMT-3".
No meu caso que estou em São Paulo, qualquer timezone GMT-3 daria na mesma?
___
pgbr-geral mailing list
pgbr-geral@listas.postgres
Basta colocar a condição na clausula WHERE.
Poste a consulta que vc já conseguiu montar para que possamos ajudar.
Em 5 de junho de 2015 15:26, Matheus Saraiva
escreveu:
> Tenho a seguinte situação.
>
> exemplo:
>
> CLIENTE
>
> id_cliente SERIAL PK,
> nome_cliente VARCHAR(50)
>
>
> T
Em 17 de março de 2015 11:39, Rafael Fialho
escreveu:
> Em 17 de março de 2015 11:36, Douglas Listas
> escreveu:
>
> Bom dia!
>>
>> Galera, esse select:
>>
>> select cpf_comprador, list(distinct nome_comprador), sum(vlr) from
>> vendas group by cpf_comprador;
>> Roda em um banco Sybase (Watcom).
Porque não força o usuário a fazer o filtro antes? Abra a tabela depois que
tiver o filtro.
Em 13 de março de 2015 13:34, Junior Miranda
escreveu:
> O usuário visualiza todos num grid e a partir dai realiza os filtros que
> desejar.
>
> Júnior Miranda
> *Analista de Sistemas*
> *Especializando e
Em 12 de março de 2015 13:39, Danilo Silva
escreveu:
> Pessoal,
>
> Qual a melhor maneira de guardar todos os inserts, updates e deletes que
> ocorrem em todas as tabelas de uma determinada base de dados?
>
> Em relação aos updates, preciso ter um histórico do que foi alterado,
> apresentando em
Em 10 de janeiro de 2015 11:38, Osvaldo Kussama
escreveu:
> Em 10/01/15, Vinicius Santos escreveu:
> > Bom dia pessoal,
> >
> > Criei um banco de dados herdando de template0 usando a codificação
> WIN1252.
> >
> > Tenho um arquivo txt codificado em A
Em 10 de janeiro de 2015 09:34, Vinicius Santos <
vinicius.santos.li...@gmail.com> escreveu:
> Bom dia pessoal,
>
> Criei um banco de dados herdando de template0 usando a codificação WIN1252.
>
> Tenho um arquivo txt codificado em ANSI, e ao tentar importá-lo com COP
Bom dia pessoal,
Criei um banco de dados herdando de template0 usando a codificação WIN1252.
Tenho um arquivo txt codificado em ANSI, e ao tentar importá-lo com COPY,
tenho o seguinte:
ERRO: sequência de bytes é inválida para codificação "UTF8": 0xc74f
HINT: Este erro pode acontecer também se
Em 15 de setembro de 2014 14:16, Alessandro Lima
escreveu:
> Boa tarde, utilizo o "Audit trigger 91plus" e desenvolvi dentro da minha
> aplicação web algumas telas para consultar estes logs.
>
> Gostaria de saber se já existe algo similar, que facilite a leitura destes
> logs ?
>
> Se realmente n
>
>
> A versão 9.1.1 tem dezenas de bugs conhecidos.
> Atualize para a versão 9.1.14 que é a versão mais recente da série 9.1
>
Farei isso e posto os resultados. Obrigado.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.pos
Olá bom dia.
Tenho um notebook com Windows 7, rodando PostgreSQL 9.1.1, apenas como
ambiente de desenvolvimento.
Está tudo bem, quando de repente o PostgreSQL pára. Não há nada no Event
Viewer sobre a queda e quando tento subir novamente o serviço, tenho o
seguinte:
2014-09-15 13:26:49 BRT LOG:
Em 8 de julho de 2014 11:01, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:
>
> Aproveitando o gancho, mês passado o Fábio Telles ministrou um
> treinamento online especificamente sobre o tema Backup/Restore com o
> PostgreSQL [1].
>
> Foram 8h (dois sábados) tratando especificamente
Em 6 de maio de 2014 13:43, Flavio Henrique Araque Gurgel
escreveu:
> Em 06-05-2014 18:38, Flavio Henrique Araque Gurgel escreveu:
>
> Alguém sabe dizer como o PostgreSQL armazena as senhas dos usuários
>>> internamente?
>>>
>>> Ao que me parece ele calcula o MD5 da senha com algum sal...
>>>
>>
Alguém sabe dizer como o PostgreSQL armazena as senhas dos usuários
internamente?
Ao que me parece ele calcula o MD5 da senha com algum sal...
Sabendo que o MD5 é vulnerável, alguém não conseguiria fazer um ataque
remotamente usando uma rainbow table?
_
>
>
> Ao menos no trecho que supracitaste não tive essa impressão. Tentando
> esclarecer, traduzo:
>
> 'Também suporta cifragem transparente de dados usando a interface de
> padrão aberto do PostgreSQL. Isso automaticamente cifra dados na base
> de dados, de modo que desenvolvedores de aplicação
2014-03-11 16:42 GMT-03:00 Fabrízio de Royes Mello
:
>
> FUJITSU Integrated System HA Database Ready SX2
>
> http://www.fujitsu.com/global/news/pr/archives/month/2014/20140228-02.html
>
"It also supports transparent data encryption using the open-standard
PostgreSQL interface. This automatically
Em 29/01/2014 22:16, Daviramos Roussenq Fortunato escreveu:
Boa Noite Lista,
Tenho uma aplicação instalada em muitos Clientes e conectam num
mesmo banco, nessa aplicação foi um SQL errado. Tenho um custo muito
alto e pouco tempo para corrigir o problema.
Tem como eu manipular esse SQL qu
Em 08/01/2014 18:21, Guimarães Faria Corcete DUTRA, Leandro escreveu:
Não atualmente. Veja, há muitas combinações de mudanças possíveis e
erros prováveis; criar um mecanismo genérico não é exatamente trivial.
O que se costuma fazer é usar DOMAINs para organizar, ou simplesmente
interrogar o ca
Em 08/01/2014 19:18, Tiago Adami escreveu:
O lado bom é: nada a ver com o elefante. Viva!
Como na grande maioria dos casos!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr
>
> > No mundo perfeito isso não deveria ser uma preocupação...Afinal, o
> software
> > é livre.
>
> Não entendi… pode explicar qual seria tua preocupação, e em que
> sistemas livres num mundo perfeito a dimirimiam?
>
Apenas por curiosidade.
Se a Salesforce usar esta contratação para "pressionar
> Já ouvi falar de piloto GNU/Linux para baixar o preço da Microsoft…
> será que a tática foi contratar o Lane para baixar o preço da Oracle,
> ou tem planos maiores mesmo?
>
No mundo perfeito isso não deveria ser uma preocupação...Afinal, o software
é livre.
Seria certo dizer que o projeto depen
>
> Em termos numéricos os zeros à esquerda não são significativos.
> Talvez você esteja se referindo a uma string de caracteres numéricos e
> não a um número?
>
Isso mesmo.
Vou usar o resultado em um length(), portanto gostaria de obter apenas
números, sem suspender os zeros à esquerda.
Não sei
>
>
> Você está falando da to_char ou da to_number??
>
Desculpe, errei o título. Estou falando de to_number.
Resolvi o caso usando regex, mas fica a dúvida a título de curiosidade.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://
Bom dia,
Existe alguma configuração a passar para o to_char(), para que ele não
suspenda os zeros iniciais?
Exemplo:
SELECT to_number( '01.451-000', 'FM' );
O resultado não irá retornar o zero inicial.
Se não existir, vou criar uma função mesmo.
Obrigado.
_
>
> Use a view user_defined_types do Information Schema.
>
> http://www.postgresql.org/docs/current/interactive/infoschema-user-defined-types.html
>
>
Ou, o mais fácil pra este tipo de coisa, o pgAdmin.
___
pgbr-geral mailing list
pgbr-geral@listas.postgr
> Estou colocando COMMENTS nas constraints com mensagens de erro mais claras.
> Quero poder converter isto:
> ERROR: new row for relation "produto" violates check constraint
> "chk_produto_precomin"
> Nisto:
> O preço de tabela do produto não pode estar abaixo do preço mínimo.
>
Você sabe o nome
>
>
> Flávio,
> imagine que você precise que um usuário final (bem lá do final
> mesmo...rs) precise conectar na base e consultar alguns dados, mas eu só
> quero que ele faça consultas e nada mais. Imagine que ele não tem
> conhecimento suficiente para fazer um script ou algo do tipo, mas c
>
>
> A EMS disse que só vai liberar atualização para 9.2 em outubro. Que coisa,
> não? O pgdiff atende o 9.2? Você usa?
>
O pgdiff trabalha de maneira diferente da ferramenta da EMS, é como o diff
do GIT ou SVN ,da uma olhada na documentação para mais detalhes, é
realmente muito simples.
Eu uso
>
> Pois é, macaco velho fica confiante demais no galho... hehehe. Mas o
> ambiente é controlado, dá pra arriscar. Os benefícios da nova versão me
> chamaram a atenção. A rotina em questão é de comparer, vou ter dar outro
> jeito (como diff do metadado, por exemplo).
>
Como já disseram existe o pg
> lembrando de linguagens de programação, algo assim:
>
> *Create constant UM = 1 as type integer;*
>
> Não me expressei completamente na pergunta, mas seria algo assim.
>
Isso não é possível.
Você só vai conseguir usar variáveis, e não constantes, dentro funções
escritas em alguma PL. plpgSQL, po
>
>
> Algo Assim:
>
> Create constant UM integer;
>
> Select UM + UM
>
> Resultado : 2
>
Isso não existe. Além disso, como o PostgreSQL iria saber que UM é igual a
1?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgres
>
> O problema não é nem tanto o ORM, mas como ele é vendido. O povo aqui no
> trampo usa Hibernate... e fica bom sim. Eles me mostraram como o hibernate
> evoluiu em algumas coisas e como dá para usar bem o cache dele a nosso
> favor e eles sabem que em muitas situações temos que passar por fora d
>
> generalizei pq não quero levantar defuntos conhecidos meus... hehehehe...
> e você esta coberto de razão.
>
Desculpe se eu dei a entender que foi uma resposta direta à vc. Não foi,
foi apenas a minha opnião.
Não estou dizendo de vc, mas tem muita gente que generaliza de maneira
errada.
__
> Javeiros são um problema de forma geral, normalmente programam de forma
> estruturada em uma linguagem orientada a objeto... sou javeiro e o mais
> difícil é dizer a um que ele não esta fazendo da forma correta...
> imagina então tirar a facilidade do "Hibernate", vixi
>
A única coisa "chata
> > Mas seria tão simples de o Postgres nao substituisse meus textos
>
> Aí é que está. Isso é texto mesmo? Ou é um binário? Você precisa da
> validação dos caracteres codificados, ou precisa da gravação
> bit‐a‐bit?
>
O componente richedit do Delphi grava arquivos em RTF[1], que são arquivos
t
>
> coisa em tráfego não. Na minha visão de DBA mesmo uma aplicação
> Desktop Client/Server deveria "Conectar --> Processar algo --> fechar
> conexão". Pena que algumas ferramentas/IDE não permitam isso por causa
> de seus componentes de acesso à dados...
>
Acho que isso não tem a ver com a ferram
>
> Em 31-07-2012 14:57, Vinicius Santos escreveu:
> > O limit trabalha depois do ORDER BY. Ou seja, primeiro os registros
> > são classificados para depois serem "limitados".
> Mas eu estou a usar sem o 'order by'. A ordem que tenho é de insercção
>
> Olá pessoal,
>
> Eu tenho uma tabela com uma ordem que não quero perder.
> Existe maneira de selecionar apenas o conteudo de uma coluna da
> primeira linha?
>
> Experimentei usar o LIMIT1 mas o postgresql não vai buscar o primeiro
> registo.
>
Negativo! Ele vai buscar na ordem correta sim.
>
> Lá vai
>
> SELECT to_char(((date_trunc('week',current_date)::date) + (i+6)), 'DAY')
> AS "DATA",
> CASE
> to_char(((date_trunc('week',current_date)::date) + (i+6)), 'DAY') WHEN '*
> SUNDAY*' THEN '*FIM DE SEMANA*' WHEN '*SATURDAY*' THEN '*FIM DE
> SEMANA*' ELSE '*DIA UTIL*'
> Cara, cuidado!
>
> "Seq scan" não é sinônimo de lentidão. Como o Tiago disse, caso a tabela
> produtos não seja muito grande (e.g. algumas páginas) é natural que o
> PostgreSQL escolha um "seq scan" ao invés de um "index scan", já que o
> "index scan" poderia acarretar mais leituras em disco que
>
>
> Com "IN" esse comportamento é bem comum. O IN é bom para um conjunto
> limitado de valores. Por exemplo, produto in (10, 20, 40, 50). Fazer
> IN para "juntar" tabelas não é a melhor opção.
> Tente fazer um join, mais ou menos assim:
>
Estou utilizando o IN com um conjunto bem limitado de val
Boa tarde pessoal,
Tenho uma view criada assim:
CREATE VIEW visao AS SELECT chave AS produto, produto FROM produtos;
Então eu faço um select assim:
SELECT chave, produto FROM visao WHERE produto = 1234;
até aqui legal. Porém quando faço:
SELECT chave, produto FROM visao WHERE produto IN ( S
> O código está em src/backend/util/adt/numeric.c.
>
>
Com a replicação fácil do problema, alguém poderá depurar. Ou pelo menos
apontar o erro, se pode ser um erro do processador, S.O ou de alguma
biblioteca. Parece ser um caso interessante.
___
pgbr-ger
> Sim. Eu perguntei porque fiz uma pesquisa nos fóruns da hackers e mais
> pessoas tiveram esse problema na conversão automática.
>
> Desculpe não ter respondido antes, eu estava em deslocamento.
>
Caramba. São Paulo está tão ruim assim?!
Será que já tem a solução? Vou dar uma pesquisada na -hack
>
> Em minha opinião, o presente caso só pode ser atribuído à alteração do
> tipo de dados da base. Para mim não ficou claro se o Vinicius
> recarregou a tabela após a modificação ou fez um update com a cláusula
> USING no comando ALTER TABLE.
>
Osvaldo. Eu fiz um ALTER TABLE sem a cláusula USING
Em 19 de julho de 2012 16:53, Vinicius Santos <
vinicius.santos.li...@gmail.com> escreveu:
> Fiz um teste com 9.1.4 aqui via psql.
>> Os valores foram devidamente arredondados (não truncados) no INSERT.
>>
>> Pergunto:
>> Versão do seu PostgreSQL?
>> Arqu
> Fiz um teste com 9.1.4 aqui via psql.
> Os valores foram devidamente arredondados (não truncados) no INSERT.
>
> Pergunto:
> Versão do seu PostgreSQL?
> Arquitetura (32 ou 64 bits) e S.O. (existem bugs que podem estar
> relacionados ao "endianess" do processador).
>
Vamos lá:
Versão: 8.4.12 - A
> Provavelmente se alguém entrar na hackers e indicar que isso é um bug
> vai tomar toco do Tom Lane.
>
Tudo bem, concordo que não é um bug. Mas inserindo o mesmo valor por
pgAdmin ele aparentemente trunca em 4 posições.
Porque não truncaria em outra aplicação cliente ? Seja qual for ela...
_
> O PostgreSQL tem uma resolução alta interna para o tipo numeric.
> Provavelmente o valor foi resultado de um cálculo que gerou os decimais
> que você está vendo.
>
> Recomendo que, na sua aplicação ou nas consultas que está fazendo,
> arredonde os valores no momento da operação de INSERT ou UPDAT
>
>
> Creio que não esteja correto não, porque o tipo de dado da coluna dele é
> NUMERIC(14,4) e parece que ele não está respeitando essa precisão... fiz
> alguns testes aqui e não consegui reproduzir aquele comportamento:
>
Também concordo com você. Ele deveria dar um erro para valores tão grande
> Logo, o PostgreSQL está agindo corretamente.
> Note que o valor armazenado é o que você viu acima.
> O que está aparecendo no SELECT seco é um arredondamento apenas na
> visualização do valor.
>
> Seu sistema deve ter inserido os dígitos extras.
>
> Não há correção no PostgreSQL nenhuma pro compo
>
> SELECT sua_coluna/1.00 FROM sua_tabela WHERE suas_condições;
>
> Ajustando para sair o resultado da linha que você está suspeitando?
>
Eu aumentei o número de zeros da divisão, até que sobrassem zeros à
esquerda.
Assim: SELECT valor/1.00
Em 19 de julho de 2012 16:01, Claudio Oliveira escreveu:
> Fala Vinicius,
>
> Tenta assim
>
> where valor = '355.55';
>
> Já vi acontecer isso, acho que corrigiram na 9 >
>
Fala Cláudio, blz?
Já tentei assim, não funciona. Ainda não testei com >=9.
__
> SELECT sua_coluna/1.00 FROM sua_tabela WHERE suas_condições;
>
> Ajustando para sair o resultado da linha que você está suspeitando?
>
Fiz assim:
SELECT valor FROM nova_tabela:
--
355.5500
355.5500
Depois:
SELECT valor/1.
Em 19 de julho de 2012 15:43, José Mello Júnior escreveu:
> E se colocasse uma expressão no where, não funcionaria?
>
> Ex: WHERE (valor+0) = 355.55
>
Não resolve, mesma coisa.
Fiz diversos testes. Na tabela original, eu isolei a coluna, exclui todas
as outras colunas deixando apenas a coluna
> O que retorna o comando:
>
> SHOW extra_float_digits;
>
O valor é 0.
>
> Provavelmente o PostgreSQL está armazenando mais dígitos internamente do
> que está mostrando.
>
> Qual é o tipo de dados do campo?
>
Numeric(14, 4).
___
pgbr-geral mailing lis
>
> Cria uma cópia da sua tabela e repita os testes nesta nova para ver se o
> problema persiste.
>
> CREATE TABLE nova_tabela AS SELECT * FROM tabela;
O problema persiste.
Usando o operador igual, não retorna. Usando o operador BETWEEN retorna.
Mas que coisa hein...
___
>
> Vc tem algum índice associado a esse campo?
>
> Caso positivo tente rodar um "reindex" nele e repita seus testes.
>
Não existe um índice. Mas para testes, eu criei ele, fiz um reindex e nada.
Existe uma CHECK( valor > 0 ), então, só pra desencargo de consciência,
removi ela também. Mas o prob
>
> Faça um teste e procure por:
>
> SELECT * FROM tabela WHERE valor BETWEEN 355.5 AND 355.6;
>
Fiz outro teste agora: "SELECT * FROM tabela WHERE valor BETWEEN 355.55 AND
355.00"; Este não retorna nada.
Porém se eu fizer "SELECT * FROM tabela WHERE valor BETWEEN 355.55 AND
355.0
> Funciona normalmente aqui comigo.
Fiz os mesmos testes que você e realmente funciona! Não consegui replicar o
problema dando INSERT manualmente, assim como vc fez.
> SELECT * FROM tabela WHERE valor BETWEEN 355.5 AND 355.6;
>
Caramba, matou a charada. Fiz valores entre 355.55 e 355.56
Agora
Boa tarde pessoal,
Hoje me deparei com uma situação muito estranha. Temos uma tabela com uma
coluna assim: "valor numeric( 14, 4 ) NOT NULL DEFAULT 0".
Quando faço por exemplo: "SELECT * FROM tabela WHERE valor = 261.61" tudo
funciona normal, porém quando faço:
"SELECT * FROM tabela WHERE valor
Pessoal boa tarde,
Tenho uma string assim: 'Pedido 123'. E tenho outra string contendo vários
pedidos separados por ponto-e-vírgula, assim: '123 ; 456 ; 789'.
Existe alguma maneira simples de verificar que o pedido 123 está dentro da
outra string?
Eu pensei em deixar a primeira string apenas com
Pessoal, rodamos PostgreSQL 8.4.8 em cima de um Slackware, Kernel 2.6.38.
Não temos problemas de performance nem nada, e estive lendo sobre o
parâmetro "bgwriter_delay" cujo valor padrão é 200ms, será que se eu
abaixasse esse valor para digamos 50ms seria algo saudável? É mais uma
curiosidade e um
> Ainda não parei pra verificar a diferenca entre Latin e Ansi, mas sei que
> Units gravadas em UTF-8 aceitam todo tipo de cacactere pelos testes que fiz
> aqui...
> Ou seja, isso é uma salada danada :)
>
> Mas devagar e com a ajuda de voces chego a uma soluçao, obrigado
>
Eu acho que pra solucion
> Talvez caiba uma nota (aqueles quadradinhos cinzas) na documentação do
> sql-grant avisando esse comportamento do COPY. Que tal mandar uma
> sugestão de patch da documentação?
>
Vou fazer isso esse fds! Concordo com suas colocações, mas ainda acho que
poderia melhorar.
_
> Não, não estaria resolvido. O COPY para um arquivo precisa de
> superusuário, pois é o usuário de sistema operacional do servidor,
> normalmente "postgres", é quem faz a escrita e ele pode escrever
> diretamente inclusive nos diretórios de dados do cluster.
>
Bom tudo bem, vou fazer o que você f
Pessoal bom dia,
Tenho a seguinte situação, faço um COPY de uma função SETOF, assim:
COPY( funcao_que_retorna_varias_linhas() ) to '/caminho/arquivo'
Até ai, tudo bem, o problema é que usuários "comuns" não conseguer dar COPY
dessa maneira. O postgres diz que somente super-usuários conseguem.
J
Em 29 de abril de 2012 22:02, Targino Silveira
escreveu:
> É pessoal o problema esta no SGDB e não no database, fiz o restore com
> sucesso em outro servidor.
>
> Agora preciso fazer um planejamento de migração da 8.3 para a 9.1 em todos
> os servidores.
>
E o problema está ee
> Quando acabo toda estrutura, queria saber se tem alguma forma para eu pegar
> essa variável, e escreva em um arquivo tipo tabela.html e tabela.php ??
>
Daria para gravar o conteúdo dessa variável em uma tabela e depois exportar
usando COPY.
___
pgbr-ge
>
> Virou festa do ódio agora?
>
> Recomendo a quem queira odiá‐lo que leia sobre a síndrome de Asperger,
> da qual é portador, e tende alcançar a magnitude de suas contribuições
> à humanidade.
>
Eu odeio entrar nestas Threads. É minha última mensagem.
Mas sempre vejo vocês falarem mal da MS, por
>
> próprio egocentrico porco do stallman.
>
Que bom. Achei que apenas eu pensava isso.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Em 5 de março de 2012 13:13, Kévio Castro escreveu:
> Não sofra, use algum software para importar.
>
Ou leia a documentação que o sofrimento vai embora também!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.or
>
> Gostaria de saber se há como desativar esta reorganização de fontes feita
> automaticamente pelo postgre?
> Tanto pelo motivo de ficar lento as vezes quanto pela dificuldade em dar
> manutenção em view's mais complexas que existem no sistema.
>
>
Não sabia que CASTS deixava querys mais lentas.
>
>
> O pgAdmin instalado é o que vem na instalação da enterprisedb.
>
> Tem como desinstalar só ele?
>
> Não conheço o instalador da EnterpriseDB.
Faça o seguinte:
1) Abra o regedit
2) Exclua a chave "frmQuery" localizada em CURRENT_USER/Software/pgAdmin
III.
_
Em 25 de janeiro de 2012 13:13, Fernando de Oliveira <
fdoturmal...@hotmail.com> escreveu:
> De acordo com esse link, não tem opção para win 64.
>
> http://www.postgresql.org/ftp/pgadmin3/release/v1.14.0/
>
> Seria o pgAdmin incompatível com win 7 64bits?
>
>
Isso não tem nada haver. Sistemas 64b
Em 25 de janeiro de 2012 11:32, Fernando de Oliveira <
fdoturmal...@hotmail.com> escreveu:
> Bom dia a todos!
>
> A ferramenta SQL do pgAdmin da minha instalação no windows 7 64 bits,
> parou de abrir. Quando peço para abrir, todo o pgAdmin trava.
>
> Alguém mais está co esse problema?
>
Qual a
>
> E aí?dá p fazer com postgresql?
>
>
Ronaldo!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Pessoal, estou tentando montar o seguinte SQL numa Query Zeos, mas está
> dando erro, não entendi, pois no pgAdmin ele aceita:
>
> select cast(('06/01/2012' ::date + (validade || ' month')::interval) as
> date) as proximo
> from mv_produtos
> where (codigo = '60')
>
É por causa dos ":" (dois-pont
>
> alguém conhece alguma IDE para gerenciamento de banco de dados PostgreSQL
> para linux no nível do EMS SQL Manager que existe somente para Windows?
>
>
No nível de qualidade do EMS eu acredito que não. O que temos que fazer é
trabalhar para deixar o pgAdmin no mesmo nível dos concorrentes comer
Pessoal, boa noite,
Estamos mudando algumas coisas no controle de estoque de nosso ERP, que já
está em funcionamento, porém algumas modificações eu quero usar chaves
naturais, e estas chaves são compostas.
Aqui demonstro um exemplo simples e fictício, em que a tabela
"deposito_produtos" tem uma c
>
> Mas sua consulta funcionará perfeitamente, como se fosse uma consulta
> local, o que não acontece com o dblink e similares, que são chamadas
> de função.
Claro, é um funcionalidade bem legal.
Mas é possível fazer isto também com DB-LINK, basta criar uma visão, como
eu fiz no exemplo. Desta ma
>
> Então FDW e PostgreSQL 9.1 são vantajosos pra você.
>
Não cheguei a verificar o que o colega Carlos disse, mas se o FDW não
repassa a clausula WHERE, apenas mudamos a face do problema.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
h
>
>
> Não alcancei o que você espera do dblink.
> Você espera que a função leve em consideração informações fora do
> escopo dos parâmetros que lhe são fornecidos?
Me expressei mal. Não seria dentro deste contexto.
Algo como uma tabela externa mesmo, mas que seja transparente. Talvez se o
DB-LINK
Pessoal, após pensar um pouco, consegui resolver o problema.
Com este select:
CREATE OR REPLACE VIEW consulta_atual AS
SELECT
substring( current_query FROM position( 'where' IN current_query ) FOR
LENGTH( current_query ) ) AS clausula
FROM
pg_stat_activity
WHERE
procpid = pg_backend_p
>
> não é melhor replicar esta tabela utilizando o bucardo ?
>
> vc terá uma melhor performance.
Não estamos utilizando replicação. Por DB-LINK as coisas ficariam mais
simples, mas se não tiver jeito após todos os neurônios tiverem pedido
arrego, vamos ter que utilizar replicação sim.
___
Em 16 de novembro de 2011 15:29, Claudio Oliveira
escreveu:
> Olá,
>
> Pela view realmente não vai funcionar.
>
> Vc terá que fazer uma função
>
E ai Claudião !! Tudo blz ???
O problema é que não podemos utilizar função. Estamos mexendo na tela de
"Produtos por Localização".
Não há como mudar
Boa tarde pessoal,
Estou com uma dúvida com uma funcionalidade que estou precisando muito.
Tenho uma view +/- assim:
CREATE OR REPLACE VIEW consultar_sao_paulo AS
SELECT produto, estoque FROM dblink('dbname=sao_paulo', 'SELECT produto,
estoque FROM estoque' )
AS tabela( produto INTEGER, es
Em 8 de novembro de 2011 17:21, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:
>
> Então sim, atualizar o PgAdmin para a versão que suporta a versão
> utilizada do PostgreSQL é importante.
>
Sim, é importante. E eu não disse o contrário.
__
Em 8 de novembro de 2011 16:20, Bruno Silva escreveu:
> E verifica qual a versão do seu pgadmin3. A versão 1.12 me parece ter
> algumas incompatibilidades mesmo, a 1.14 é compatível com a 9.1 e
> aceita também conexões ao 8.4
>
Como o Leandro disse, o pgAdmin não tem nada a ver, ele apenas invoca
Em 18/10/2011 16:24, Guimarães Faria Corcete DUTRA, Leandro escreveu:
> Isso não tem muito a ver com o PgAdmin, é linguagem SQL. O PgAdmin é
> só uma interface…
Seguindo a lógica, o certo seria pgAdmin e não PgAdmin. ;)
___
pgbr-geral mailing list
pgbr-g
Boa noite pessoal,
Preciso de uma idéia/sugestão de como garantir o seguinte:
Temos um ERP com uma tabela de saídas e outra com uma tabela de
entradas, e uma terceira com o saldo das duas.
Por Exemplo: o total da tabela de saídas deu 100 e o total da tabela de
entradas deu 110, ou seja o saldo é
Em 03/09/2011 12:25, Leandro Guimarães Faria Corce DUTRA escreveu:
>
> O Firebird é uma bifurcação do Interbase. Até, na ausência de
> documentação própria, a do Firebird era a da última versão fo
> Interbase antes da bifurcação, mais o acumulado das notas de versão do
> Firebird desde então…
1 - 100 de 173 matches
Mail list logo
