Re: [pgbr-geral] Dúvida com modelagem de Controle de Documentos Entregues e com consulta SQL
2016-03-02 8:11 GMT-04:00 Andre Cavalcante :
> Olá,
>
> 2016-03-01 21:21 GMT-04:00 Leandro Guimarães Faria Corcete DUTRA <
> l...@dutras.org>:
>
>> Le 1 mars 2016 17:17:02 GMT-03:00, Andre Cavalcante <
>> andre.d.cavalca...@gmail.com> a écrit :
>> >
>> >id serial
>>
>> Você não definiu nenhuma chave natural. Fica muito difícil entender um
>> modelo sem as chaves naturais.
>>
>
> obrigado pela resposta...
>
> Ok. Esqueci de indicar. Segue abaixo:
>
> Aprendiz
> ---
> id serial
> matricula varchar
> nome varchar
> ... outros campos
>
>
> ItemHistorico
> --
> id serial {PK - cada item tem um número que o identifica unicamente. A
> chave candidata seria dahoraEvento+idAprendiz, obviamente por se tratar de
> um evento discreto no tempo}
> idAprendiz integer {FK para Aprendiz, formando uma relação de 1 aprendiz
> para muitos itens. Na modelagem OO eu tenho List em Aprendiz}
> nomeEvento varchar
> descricao varchar
> datahoraEvento Timestamp
> detalheEvento integer //aqui eh um número que define o tipo do detalhe
> do evento, se é entrega de documentação ou se é outro tipo de evento
> notas
>
>
> Anexo
>
> id serial {PK - cada anexo tem um id, sem grandes problemas aqui. Não há
> chave candidata (posso colocar até o mesmo arquivo várias vezes, mas o
> sistema não precisa verificar isso, cabendo ao operador saber o que está
> fazendo}
> descricao varchar
> dados bytea
> idItemHistorico {FK para ItemHistorico, formando uma relação de 1 item
> para muitos anexos. Na modelagem OO eu tenho List em ItemHistorico}
>
>
> DocEntregue
>
> idItemHistorico integer {PK - mesmo que o id do item. No OO DocEntregue é
> filho de ItemHistorico}
> detalheEvento integer {pseudo FK - é o número do detalhe do evento,
> neste caso do tipo Documento Entregue}
> rg boolean //true se entregou o RG
> "RG" varchar //o número do RG
> "dataEmissaoRG" Date //a data de emissão do RG
> cpf boolean//true se entregou o CPF
> "CPF" varchar//o número do CPF
> ctps boolean // true para a CTPS
> "CTPS" varchar // número de séria da CTPS
> cr boolean //true se entregou o comprovante de residencia
> pis boolean //true se entregou o PIS
> "PIS" varchar //número do PIS
> nre boolean //true se entregou o registro de estrangeiro (para o caso)
> "NRE" varchar //número do registro de estrangeiro
> ce boolean// comprovante de escolariade
> "CE" String // número ou protocolo do CE
> notas varchar //observações e notas
>
> Esse é o conjunto de tabelas. Tenho um conjunto de classes (OO) que são
> mapeadas aqui.
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Junção Crosstab?
Bom dia, pessoal. Tenho uma tabela assim: id_hor descricao_hor 1 07:30 2 08:20 3 09:10 4 10:15 5 11:05 6 11:55 Tablela Agenda - Relacionada com horarios através de idhora_ag: id_ag data_ag professor_agturma_ag recurso_ag idhora_ag 1 01/02/2016Prof ATurma 1 Lab 1 2 01/02/2016Prof BTurma 2 Tab 2 3 01/02/2016Prof CTurma 3 Lab 3 4 01/02/2016Prof DTurma 4 Tab 4 5 01/02/2016Prof ETurma 5 Lab 5 6 01/02/2016Prof FTurma 6 Tab 6 Preciso montar um select de acordo com a data retornando: DESCRICAO_HOR LAB TAB 07:30 Prof A 08:20 Prof B 09:10 Prof C 10:15 Prof D 11:05 Prof E 11:55 Prof E Pesquisando acho que é com crosstab, mas ainda não sei como proceder. []´s Stclara. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Dúvida com modelagem de Controle de Documentos Entregues e com consulta SQL
2016-03-02 9:13 GMT-03:00 Andre Cavalcante :
> Aprendiz
> ---
> id serial
> matricula varchar
> nome varchar
Cada um é uma chave? Ou a chave são os dois atributos?
> ItemHistorico
> --
> id serial {PK - cada item tem um número que o identifica unicamente. A
> chave candidata seria dahoraEvento+idAprendiz, obviamente por se tratar de
> um evento discreto no tempo}
Com uma chave natural de apenas dois atributos, eu pensaria seriamente
em simplificar o modelo eliminando a chave artificial.
> Anexo
>
> id serial {PK - cada anexo tem um id, sem grandes problemas aqui. Não há
> chave candidata (posso colocar até o mesmo arquivo várias vezes, mas o
> sistema não precisa verificar isso, cabendo ao operador saber o que está
> fazendo}
Isso nunca dá certo. Mesmo que desse operacionalmente, indica um
problema mais grave de entendimento de modelo e de negócio.
De qualquer maneira, tens outras questões específicas sobre teu modelo
proposto? Ou o que queres são comentários de base como os que fiz até
agora.
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Paradas na replicação do PostgreSQL - Diagnóstico
Olá ontem tivemos duas paradas na replicação do primário para o standby, ou seja, o standby não recebeu mais atualizações do primário. Após mais de 4 horas assim, reiniciamos o standby e tudo voltou ao normal. Não existem mensagens de erro no log do PostgreSQL primário nem no standby. Nem o OSWatcher nem o Zabbix exibem problemas de conectividade, disco ou SO. Existe alguma maneira de diagnosticar melhor esse problema? Seria interessante alguma solução que não fosse aumentar a verbosidade do log, pois posso ter restrições de armazenamento se deixasse em modo debug durante todo o tempo. Segue minhas configurações: PostgreSQL 9.3.10 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16), 64-bit Red Hat Enterprise Linux Server release 6.7 (Santiago) wal_level = hot_standby archive_mode = on archive_command = '/usr/local/bin/copy_archive_logs.sh %p %f' archive_timeout = 300 max_wal_senders = 5 wal_keep_segments = 64 wal_sync_method = open_sync Obrigado -- Everton ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Paradas na replicação do PostgreSQL - Diagnóstico
Olá ontem tivemos duas paradas na replicação do primário para o standby, ou seja, o standby não recebeu mais atualizações do primário. Após mais de 4 horas assim, reiniciamos o standby e tudo voltou ao normal. Você faz consultas sobre o standby? Você faz dump sobre o standby? Não existem mensagens de erro no log do PostgreSQL primário nem no standby. Nem o OSWatcher nem o Zabbix exibem problemas de conectividade, disco ou SO. Existe alguma maneira de diagnosticar melhor esse problema? Monitorar a visão pg_stat_replication no servidor principal. Lá você pode ver todos os standby conectados e o atraso de replicaçã, seja no envio dos dados, no recebimento e na aplicação do outro lado. Seria interessante alguma solução que não fosse aumentar a verbosidade do log, pois posso ter restrições de armazenamento se deixasse em modo debug durante todo o tempo. Não há necessidade num primeiro momento. Segue minhas configurações: PostgreSQL 9.3.10 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 9.3.11 disponível, atualize o quanto antes! 4.4.7 20120313 (Red Hat 4.4.7-16), 64-bit Red Hat Enterprise Linux Server release 6.7 (Santiago) wal_level = hot_standby archive_mode = on archive_command = '/usr/local/bin/copy_archive_logs.sh %p %f' archive_timeout = 300 max_wal_senders = 5 Você tem 5 standby conectados? ou você faz uso de pg_basebackup mais alguma outra ferramenta? wal_keep_segments = 64 wal_sync_method = open_sync Nem sempre a melhor opção, já usou a ferramenta pg_test_fsync? []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] Paradas na replicação do PostgreSQL - Diagnóstico
On 02-03-2016 11:22, Everton Berz wrote: > ontem tivemos duas paradas na replicação do primário para o standby, ou > seja, o standby não recebeu mais atualizações do primário. > Após mais de 4 horas assim, reiniciamos o standby e tudo voltou ao normal. > O que você quis dizer com parou de replicar? Dependendo do cenário, uma simples consulta pode "parar" a replicação com algum bloqueio (aka lock). Quais os valores dos parâmetros max_standby_*_delay? > Não existem mensagens de erro no log do PostgreSQL primário nem no standby. > Quando a conexão de replicação cai de maneira inesperada você tem uma mensagem no log. O processo wal sender e/ou wal receiver estava presente nos respectivos servidores? Você executou um strace no wal sender? > Nem o OSWatcher nem o Zabbix exibem problemas de conectividade, disco ou SO. > Isso está parecendo consultas longas com bloqueios. > Existe alguma maneira de diagnosticar melhor esse problema? > Qualquer problema na replicação é reportado no log. Recordo-me que há uma correção na 9.3.11 cuja mensagem de ERRO de conexão não era emitida após receber um EOF. Fix premature clearing of libpq's input buffer when socket EOF is seen Atualize sua versão. -- 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
[pgbr-geral] Saber se a Base tem tabelas criadas.
Boa tarde Pessoal,
Estou tentando saber se uma base criada foi executa o restore ou não.
Praticamente é saber se ela tem alguma tabela (estrutura) criado.
Tentei verficar pelo tamanho pelos sequintes comandos:
select pg_size_pretty(pg_database_size('NomeBase'));
SELECT pg_size_pretty(pg_database_size(current_database()));
Porém sempre irá retornar um tamanho que seja minimo. Mais pode variar de
database para database, tem algum comando que da para verificar se uma base
tem alguma estrutura de objetos criados ou se não tem nada ainda (como se
estivesse aguardando um restore) ?
--
*Bruno da Cunha Felipe*
Enviado com MailTrack
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] PgDay Curitiba na Celepar - É amanhã!!!
Prezados colegas, É amanhã o PgDay Curitiba na Celepar. Se você ainda não se inscreveu, ainda da tempo. Data: *03 de Março de 2016 das 8h30 às 17h*. Local: *CELEPAR* - Tecnologia da Informação e Comunicação do Paraná Sala: *Auditório Jarbas Pessoa de Oliveira* Programação disponível no site. Inscrições (1kg de alimento): http://www.pgdaycuritiba.pr.gov.br/ *Vagas limitadas.* Atenciosamente, Comissão organizadora do PgDay Curitiba na Celepar *Francisco Summa Netto* DBA PostgreSQL - Celepar franciscosu...@celepar.pr.gov.br www.pgdaycuritiba.pr.gov.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] Saber se a Base tem tabelas criadas.
Acho que a consulta abaixo pode te ajudar:
SELECT esquema, tabela,
pg_size_pretty(pg_relation_size(esq_tab)) AS tamanho,
pg_size_pretty(pg_total_relation_size(esq_tab)) AS tamanho_total
FROM (SELECT '\"' ||tablename|| '\"' AS tabela,
schemaname AS esquema,
schemaname||'.'||tablename AS esq_tab
FROM pg_catalog.pg_tables
WHERE schemaname NOT
IN ('pg_catalog', 'information_schema', 'pg_toast')
) AS x
ORDER BY pg_total_relation_size(esq_tab) DESC
At.
Francisco Junior
Em 2 de março de 2016 13:27, Bruno Felipe
escreveu:
> Boa tarde Pessoal,
>
> Estou tentando saber se uma base criada foi executa o restore ou não.
> Praticamente é saber se ela tem alguma tabela (estrutura) criado.
>
> Tentei verficar pelo tamanho pelos sequintes comandos:
>
> select pg_size_pretty(pg_database_size('NomeBase'));
>
> SELECT pg_size_pretty(pg_database_size(current_database()));
>
>
> Porém sempre irá retornar um tamanho que seja minimo. Mais pode variar de
> database para database, tem algum comando que da para verificar se uma base
> tem alguma estrutura de objetos criados ou se não tem nada ainda (como se
> estivesse aguardando um restore) ?
>
>
> --
> *Bruno da Cunha Felipe*
>
>
>
>
>
> Enviado com MailTrack
>
>
> ___
> 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] Driver DBExpress
Neste exato momento, estamos mudando de delphi7 para XE5 e junto utilizando FireDac, tudo isto em cima do PostgreSQL-8.2. Optamos por adequar o sistema primeiro, até porque, pegaríamos a versão mais estável do FireDac que nos dá um acesso nativo ao banco com performance superior a outros tipos de conexões de outras empresas. Já com 95% de todos os nossos sistemas e junto o principal(ERP) convertidos para XE5 e FireDac, estamos partindo agora para instalação e testes em cima do PostgreSQL-9.5 FireDAC é o melhor e o mais estável!!! Parabéns a Fabrizio e Guedes pela iniciativa dos vídeos. Marcos André G.A Trabin Software & Consulting - www.trabin.com.br *Blog:* http://lgerardlucas.blogspot.com/ *Bl**og:* http://versosalmaepropriedade.blogspot.com.br/ *twit**ter:* http://twitter.com/lgerardlucas Em 1 de março de 2016 09:35, Izaque Maciel escreveu: > > > Em 1 de março de 2016 08:44, Edinelson escreveu: > >> Obrigado pela informações, porem a mudança no momento seria muito grande >> e pretendo mudar aos poucos e o primeiro passo seria mudar somente a base >> de dados e em 2o passo mudar Delphi para versão mais nova onde poderia >> mudar forma acesso. >> >> Grato >> >> >> "Izaque Maciel" escreveu na notícia da >> mensagem:CAN0G60pWeEf=b-KHYdNxNOQO6cXh=5aFCUMWDWqvLMLCBk=s...@mail.gmail.com. >> .. >> >> Em 29 de fevereiro de 2016 15:20, Edinelson >> escreveu: >> >>> Olá, >>> >>> Sou novato em PostgreSQL e estou fazendo testes para migrar uma >>> aplicação que tenho em PervasiveSQL para PostgreSQL, ela esta desenvolvida >>> em Delphi 2005 com acesso via DBExpress estou tentando mudar o mínimo >>> possível na aplicação por isso estou tentando utilizar driver DBExpress >>> para PostgreSQL, pelo que pesquisei encontrei 2 drives até momento um pago >>> que é da Devart e outro free que é DbxOpenODBC, alguém tem alguma sugestão >>> ou que vocês indicariam? >>> >>> Grato >>> >>> Edinelson >>> >>> ___ >>> pgbr-geral mailing list >>> pgbr-geral-b/urxocn8+hxqfz5go68majmpyqws...@public.gmane.org >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> >> >> Segue o link de como realizar a migração: >> http://docwiki.embarcadero.com/RADStudio/XE8/en/DbExpress_Application_Migration_(FireDAC) >> >> -- >> ___ >> 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 > > > Tudo bem, mas só uma opinião. Se você vai mudar, mude para Firedac, os > ganhos são imensos. Há uma versão do Firedac para funcionar apartir do delphi > 7, ainda em estado AnyDac, que foi de quando a Embarcadero adquiriu, mas > não havia mudado toda a estrutura interna dos nomes dos componentes. Você > pode utilizar esta versão que roda a partir do delphi 7 e posteriormente > utilizar o conversor de AnyDac para Firedac. > Só uma opnião minha, eu também utilizava esse drive DBExpress da Devart. > > > ___ > 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] parametro maintenance_work_mem
On 01-03-2016 11:30, Luiz Henrique wrote: > Pessoal, > > Temos uma aplicação JBOSS que frequentemente apresenta a mensagem de log > conforme abaixo. As vezes causa lentidão no uso da aplicação. Desconfio > que o parâmetro maintenance_work_mem esteja "tímido", muito pequeno. > Gostaria da sugestão dos colegas, obrigado! > > *** log do postgresql > > LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp7263.54", size 1622016 > > *** log da aplicação JBOSS > > [org.hibernate.util.JDBCExceptionReporter] (ajp-172.24.2.38-8209-22) SQL > Warning: 0, SQLState: 0 > [org.hibernate.util.JDBCExceptionReporter] (ajp-172.24.2.38-8209-22) > temporary file: path "base/pgsql_tmp/pgsql_tmp10141.12", size 1622016 > > *** parametro do postgresql.conf > > maintenance_work_mem = 512MB > A GUC maintenance_work_mem é utilizada para atividades como criar índices e vacuum. Tais atividades também geram arquivos temporários. Pelo nome do temp file "pgsql_tmp7263.54" parece ser a reconstrução de um data file (por ALTER TABLE, REINDEX, CREATE INDEX, VACUUM FULL, etc). Porque no final ele tem o ".54" que indica o segmento de 1GB que está sendo criado. Veja nos logs qual comando está produzindo esse arquivo temporário. Provável sim que vc precise aumentar o m_w_m. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] parametro maintenance_work_mem
On 02-03-2016 17:24, Fabrízio de Royes Mello wrote: > > [...corte...] > > Porque no final ele tem o ".54" que indica o segmento de 1GB que está > sendo criado. > Um detalhe, não verifiquei se essa informação acima é verdadeira... vou dar uma olhada e em seguida confirmo 100%. > Veja nos logs qual comando está produzindo esse arquivo temporário. > Provável sim que vc precise aumentar o m_w_m. > Só para demonstrar um caso de teste de geração de "temp files" pelo "VACUUM FULL". fabrizio=# CREATE TABLE foo(id SERIAL PRIMARY KEY, name VARCHAR(100)); CREATE TABLE fabrizio=# INSERT INTO foo(name) SELECT 'Name '||id FROM generate_series(1, 10) AS id; INSERT 0 10 fabrizio=# INSERT INTO foo(name) SELECT 'Name '||id FROM generate_series(1, 10) AS id; INSERT 0 10 fabrizio=# INSERT INTO foo(name) SELECT 'Name '||id FROM generate_series(1, 10) AS id; INSERT 0 10 fabrizio=# \dt+ foo List of relations Schema | Name | Type | Owner | Size | Description +--+---+--+---+- public | foo | table | fabrizio | 13 MB | (1 row) fabrizio=# SET client_min_messages TO log; SET fabrizio=# SET log_temp_files TO 0; SET fabrizio=# SET maintenance_work_mem TO '1MB'; SET fabrizio=# VACUUM FULL foo; LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp13510.3", size 6004736 STATEMENT: VACUUM FULL foo; LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp13510.3", size 6004736 VACUUM Se ajustar o maintenance_work_mem ele não precisa do disco. fabrizio=# SET maintenance_work_mem TO '32MB'; SET fabrizio=# VACUUM FULL foo; VACUUM Só para demonstrar a todos que não é "apenas" o "work_mem" que influencia na geração de arquivos temporários no PostgreSQL. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento signature.asc Description: OpenPGP digital signature ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] parametro maintenance_work_mem
On 02-03-2016 17:24, Fabrízio de Royes Mello wrote: > Pelo nome do temp file "pgsql_tmp7263.54" parece ser a reconstrução de > um data file (por ALTER TABLE, REINDEX, CREATE INDEX, VACUUM FULL, etc). > Porque no final ele tem o ".54" que indica o segmento de 1GB que está > sendo criado. > O 54 é um contador por sessão, ou seja, naquela conexão já foram criados 54 arquivos temporários. Portanto, não quer dizer que seja uma operação em um índice/tabela/visão materializada grande. -- 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
[pgbr-geral] Minimal Database dump file
Olá,
Estou querendo fazer um dump do mínimo necessário (para ambiente de testes).
Seria interessante ter as últimas 1000 rows por exemplo das tabelas.
Então estava pensando em algo:
> pg_dump dbname --schema-only -f db_schema.sql
CREATE OR REPLACE FUNCTION _save_top_1000_row_tables(chemin file_path)
> RETURNS character varying AS
> $BODY$declare
> _temps timestamp without time zone;
> begin
> execute 'copy (SELECT * FROM table1 limit 1000 offset 0) TO ''' ||
> file_path||'table1.txt''';
> execute 'copy (SELECT * FROM table2 limit 1000 offset 0) TO ''' ||
> file_path||'table2.txt''';
> execute 'copy (SELECT * FROM table3 limit 1000 offset 0) TO ''' ||
> file_path||'table3.txt''';
> return ('OK');
> end;$BODY$
> LANGUAGE plpgsql VOLATILE
> COST 100;
Mas deste modo eu não teria as foreign keys certo?
Há outro modo de fazer? Alguém tem alguma ideia?
* estou usando PostgreSQL 9.2
Obrigado.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
