Pessoal,
Comecei agora a mexer com o PostgreSQL e estou convertendo uma proc do
sql,para funcionar como uma function no postgres.
E gostaria de ajuda pois estou com bastante dificuldades.
gostaria de saber se existe algum erro nessa linha.
open myCursor
fetch next from myCursor into
Dá um olhada na sintaxe do comando For record in query loop.
Em 4 de março de 2010 09:56, Amilton Junior aagr...@gmail.com escreveu:
Pessoal,
Comecei agora a mexer com o PostgreSQL e estou convertendo uma proc do
sql,para funcionar como uma function no postgres.
E gostaria de ajuda pois
Eu dei uma olhada, mas nao consegui entender como utilizaria.
Marcone-2 wrote:
Dá um olhada na sintaxe do comando For record in query loop.
--
View this message in context:
http://old.nabble.com/Problema-cursor-tp27780382p27781039.html
Sent from the PostgreSQL - Brasil mailing list
LinkedIn
Fabricio Veiga requested to add you as a connection on LinkedIn:
--
Mateus,
I'd like to add you to my professional network on LinkedIn.
- Fabricio
Accept invitation from Fabricio Veiga
Vou te dar um exemplo:
CREATE FUNCTION sua_funcao() RETURNS seu_retorno AS $$
DECLARE
myRec RECORD;-- Aqui declaramos a variavel que vai receber o
resultado do select que desejamos percorrer
BEGIN
FOR myRec IN SELECT * FROM minha_tabela LOOP-- Aqui ele vai
percorrer todos os
Estou prestes a fazer uma reforma no meu ERP e uma das coisas que está me
incomodando é o cadastro de pessoas. Não pude usar CPF/CNPJ como chave
primária natural porque, conforme já foi dito aqui várias vezes, muitos
clientes diferentes usam o mesmo CNPJ, especialmente órgãos públicos. Para
dar um
Sugiro que se necessario adicione as primeiras posições antes do CNPJ
o codigo do estado (De acordo com o IBGE) e o codigo do municipio (de
acordo com o IBGE) talvez consiga algo mesclando essas informações com
o CNPJ.
at
Em 4 de março de 2010 13:28, Alexsander Rosa
alexsander.r...@gmail.com
Use uma pk artificial e seja feliz. Fuja de pks compostas, elas ainda vao te
dar uma bela dor de cabeca.
Abraco
Joares Luis Dalorsoleta joa...@speedlinux.com.br escreveu:
Sugiro que se necessario adicione as primeiras posições antes do CNPJ
o codigo do estado (De acordo com o IBGE) e o codigo
Eu tentei utilizar desse modo,espero q corretamente...
Mas não deu certo, agora está aparecendo um erro q parece ser o codigo todo:
ERRO: erro de sintaxe em ou próximo a INSERT
LINE 1: ...ocumento CHAR(10) ,co_ocorrencia_cheque integer ) INSERT INT...
CONTEXT: SQL statement in PL/PgSQL
Concordo com o Fabiano.
2010/3/4 Wolak Sistemas - Fabiano Machado Dias fabi...@wolaksistemas.com.br
Use uma pk artificial e seja feliz. Fuja de pks compostas, elas ainda vao
te dar uma bela dor de cabeca.
Abraco
Joares Luis Dalorsoleta joa...@speedlinux.com.br escreveu:
Sugiro que se
Em 4 de março de 2010 14:04, HERALDO BORGES heraldobor...@gmail.comescreveu:
Concordo com o Fabiano.
+1 por chave artificial...
--
Fabrízio de Royes Mello
Blog sobre TI: http://fabriziomello.blogspot.com
___
pgbr-geral mailing list
Sei de algumas que geral instruções DDL para sincronizar esquemas, seria
interessante usar para DML para sincronizar os dados -- se bem que na
maioria das vezes um DUMP/RESTORE resolve o problema. :-) Imagino que seja
algo que precise ser rodado de tempos em tempos, em produção, sem a
Agora o erro já é de sintaxe mesmo...
Aí só com o código para tentar dar alguma dica.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
O codigo agora esta assim:
CREATE FUNCTION public.spRel_RelatorioAnaliticoBanco(var_cod_ctr_prc
integer) RETURNS SETOF ty_bancoRemetente AS $$
DECLARE
--Declaracao das variaveis com os valores que sera utilizados
myRec record;
Pessoal,
Venho com algo simples,vcs saberiam me dizer quais as linguagem suportadas pelo
postgres 8.3?
Ats
Paulo
Veja quais são os assuntos do momento no Yahoo! +Buscados
2010/3/4 Wolak Sistemas - Fabiano Machado Dias
Use uma pk artificial e seja feliz. Fuja de pks compostas, elas ainda vao
te dar uma bela dor de cabeca.
Em 4 de março de 2010 14:04, HERALDO BORGES heraldobor...@gmail.com escreveu:
Concordo com o Fabiano.
Vocês já precisaram mesclar umas 5
Em 4 de março de 2010 14:52, paulo matadr saddon...@yahoo.com.br escreveu:
Pessoal,
Venho com algo simples,vcs saberiam me dizer quais as linguagem suportadas
pelo postgres 8.3?
Caro Paulo,
Na documentação [1] constam algumas das possibilidades de linguagens... além
destas posso destacar:
Olá a todos.
Estou enfrentando um pequeno problema para implementar um servidor de
desenvolvimento com Windows Vista Business Service Pack 2 e PostgreSQL
8.4.2-1. Baixei o EnterpriseDB one click installer para fazer a
instalação do PG na estação de desenvolvimento, executo o processo com
2010/3/4 aagrjr aagr...@gmail.com:
O codigo agora esta assim:
CREATE FUNCTION public.spRel_RelatorioAnaliticoBanco(var_cod_ctr_prc
integer) RETURNS SETOF ty_bancoRemetente AS $$
DECLARE
--Declaracao das variaveis com os valores que sera utilizados
myRec
Vocês já precisaram mesclar umas 5 bases, cada uma com uns 150 GB de
dados, aproximadamente 800 tabelas, com 90% delas contendo chaves
artificiais? Isso sim que é dor de cabeça.
Procurem evitar chaves artificiais, mas se não tiver jeito usem-nas.
Mas evite-as.
Sim, chaves artificiais podem
Em 4 de março de 2010 13:28, Alexsander Rosa
alexsander.r...@gmail.com escreveu:
Uma possibilidade é usar uma chave composta, tipo CNPJ + chave extra onde
esta chave extra tem NULL em todas as PF e quase todas as PJ. Quando uma PJ
pertencer a mais de um cliente (órgãos públicos, universidades,
Bom,realmente estava bem estranho esse create type la dentro da funçao, antes
eu imaginava que ele teria q criar o tipo toda vez q executasse,mas agora
entendi q nao é assim,entao ja removi..
Agora,usando o create table as, eu eliminaria o comando insert,e ja criaria
a tabela inserindo direto o
Em 4 de março de 2010 15:34, aagrjr aagr...@gmail.com escreveu:
(...)
Agora,usando o create table as, eu eliminaria o comando insert,e ja criaria
a tabela inserindo direto o retorno da consulta?Dessa forma??
Por exemplo:
CREATE TABLE tb_pessoa_fisica AS SELECT nome::varchar(50),
2010/3/4 Joares Luis Dalorsoleta joa...@speedlinux.com.br:
Sugiro que se necessario adicione as primeiras posições antes do CNPJ
o codigo do estado (De acordo com o IBGE) e o codigo do municipio (de
acordo com o IBGE) talvez consiga algo mesclando essas informações com
o CNPJ.
Não, isso seria
Pelo q entendi da ultima resposta eu fiz assim...
CREATE temporary TABLE temp_CHQOCOR AS
SELECT
CCS.nu_cheque::CHAR(7),ICF.co_cheque_imagem_documento::CHAR(10),CHOS.co_ocorrencia_cheque::integer
FROM
ceatb029_chqe_ocrnca_sr CHOS
JOIN ceatb057_imagem_chqe_formal_sr ICF
Sim, na verdade eu editei o texto várias vezes e este detalhe passou
despercebido. Este campo, chave_extra, ficaria com um valor tipo 0 (se for
inteiro) ou brancos (se for texto) na maioria dos casos. Mas tenho minhas
dúvidas se esta é mesmo a melhor solução, acho que no fim vai ser melhor
usar
Em 4 de março de 2010 16:00, Alexsander Rosa
alexsander.r...@gmail.comescreveu:
Sim, na verdade eu editei o texto várias vezes e este detalhe passou
despercebido. Este campo, chave_extra, ficaria com um valor tipo 0 (se for
inteiro) ou brancos (se for texto) na maioria dos casos. Mas tenho
Em 4 de março de 2010 16:00, Alexsander Rosa
alexsander.r...@gmail.com escreveu:
Neste cenário, cada servidor tem suas (poucas) SEQUENCES independentes
(estão fora da replicação) e as PK de algumas tabelas são chaves compostas
que incluem a coluna id_servidor. Os clientes acabam recebendo um
Leandro:
Em 4 de março de 2010 16:30, Leandro DUTRA
leandro.gfc.du...@gmail.comescreveu:
2010/3/4 Alexsander Rosa alexsander.r...@gmail.com:
Neste cenário, cada servidor tem suas (poucas) SEQUENCES independentes
(estão fora da replicação) e as PK de algumas tabelas são chaves
compostas
Podem me chamar de ultrapassado, mas nunca simpatizei com UUIDs.
Em 4 de março de 2010 16:43, Tarcísio Sassara
sassara.tarci...@gmail.comescreveu:
Em 4 de março de 2010 16:00, Alexsander Rosa
alexsander.r...@gmail.com escreveu:
Neste cenário, cada servidor tem suas (poucas) SEQUENCES
Olá,
pl/r,pl/proxy,pl/python,c,pl/pgsql...
[]'s
Luigi Castro Cardeles
Em 4 de março de 2010 15:04, Fabrízio de Royes Mello
fabriziome...@gmail.com escreveu:
Em 4 de março de 2010 14:52, paulo matadr saddon...@yahoo.com.brescreveu:
Pessoal,
Venho com algo simples,vcs saberiam me dizer
2010/3/4 Alexsander Rosa alexsander.r...@gmail.com:
Podem me chamar de ultrapassado, mas nunca simpatizei com UUIDs.
Mór di quê?
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191
Em 4 de março de 2010 14:52, paulo matadr saddon...@yahoo.com.br escreveu:
Pessoal,
Venho com algo simples,vcs saberiam me dizer quais as linguagem suportadas
pelo postgres 8.3?
Dê uma olhada em:
http://www.postgresql.org/docs/current/interactive/external-projects.html
lá você terá
Em 4 de março de 2010 16:53, Alexsander Rosa
alexsander.r...@gmail.com escreveu:
Sim, tudo é replicado para todos os servidores (exceto as sequences).
Provavelmente existem pessoas 9502/2, 9502/16, 9502/101...
Não detona relatórios essas duplicidades?
Relatórios do tipo Ranking podem mostrar
+1 (Falou e disse!)
From: Wolak Sistemas - Fabiano Machado Dias
fabi...@wolaksistemas.com.br
Subject: Re: [pgbr-geral] Usando CPF/CNPJ como PK
Use uma pk artificial e seja feliz. Fuja de pks compostas, elas ainda vao te
dar uma bela dor de cabeca.
Abraco
Ah, questão de prática.
Tenho 900 tabelas para brincar e de proporção deve dar uns 60% com PK
artifical contra 40% sem.
Realmente base com 150GB eu não tenho, mas no meu caso a dor de cabeça é
cuidar dos malditos 40% sem PK artificial em bases muito menores.
Atenciosamente,
Mozart Hasse
From:
Rapaz eu não me lembro acho que tive esse problema no win 7 também não
sei se é o mesmo. Resolvi indo antes da instalação nos serviços e
ativando o serviço Logon secundário como automático. Se tratando do
janelão é bom reiniciar depois para dar sorte :)
Vinicius
Claro que não detona, são meras chaves compostas -- e com apenas DUAS
colunas. Um exemplo pior de chave composta é o da tabela dos cupons fiscais,
cuja PK tem quatro colunas (data, nº do ecf, nº do cupom e nº da loja),
todas chaves NATURAIS. Os próprios equipamentos fiscais geram estes dados.
Em
Em 4 de março de 2010 20:13, Mozart Hasse mozart.ha...@usa.net escreveu:
Ah, questão de prática.
Tenho 900 tabelas para brincar e de proporção deve dar uns 60% com PK
artifical contra 40% sem.
Realmente base com 150GB eu não tenho, mas no meu caso a dor de cabeça é
cuidar dos malditos 40% sem
39 matches
Mail list logo
