2007/9/12, Euler Taveira de Oliveira <[EMAIL PROTECTED]>: > Leandro DUTRA wrote: > > > Sim, de uma maneira muito simples: definem-se as restrições de > > integridade (CONSTRAINTs) sobre os DOMAINs — NOT NULL, CHECK, mesmo > > DEFAULT que não é uma restrição de integridade. Não lembro se cabe > > FOREIGN KEY também. > > > O problema que vejo em uso de domínio ao invés do tipo é que o > PostgreSQL não se comporta "bem" na transformação domínio <-> tipo em > algumas partes (como planejador, otimizador). Digo isso porque já vi > consultas [sub|super]estimadas com uso de domínios.
Será que você pode ser mais específico? Ißo é *muito* intereßante, porque minha prática é usar DOMAINs extensivamente, mas nunca enfrentei os volumes que você enfrenta. Aliás me ſurpreende um bocado, porque os DOMAINs SQL ſão apenas um fator de organização do DDL, como o Leonardo bem apontou apenas um apelido para definições que se poderiam fazer diretamente nos CREATE TABLE. Como ſerá que eles confundem o planejador? E mais uma pergunta: quando você fala 'planejador, otimizador', são duas partes diferentes? Sempre pensei em otimizador como o que planeja a execução dos comandos, até achei bom teu achado do termo planejador como tradução de /optimizer/ até perceber que você estava listando duas coisas diferentes… > >> Não que esteja querendo ser chato, mas esse tipo de entendimento é > >> importante inclusive para o nosso VP. > > > Claro, mas em todas as traduções do PostgreSQL utilizamos restrição. ;) > Vou adicionar como segunda opção. Ignorância minha, infelizmente não estou envolvido com eßas traduções embora já tenha querido fazê-lo. Geralmente vou direto à fonte. Como está traduzido por exemplo no Date? > > Hm, na verdade o nosso elefante está ficando mais estrito, impedindo > > operações que antes eram toleradas… o que ilustra como deve funcionar: > > a restrição para comparação deveria ser implícita na própria definição > > dos tipos. > > > Tenho que discordar neste ponto. O principal ponto de remover algumas > comparações implícitas (com tipo text) na 8.3 [1] foi o retorno de > resultados inesperados com o PostgreSQL fazendo suposições erradas (vide > comentários no capítulo de conversão (aka 'casting') entre tipos em > manuais de linguagens de programação interpretada). Quando você diz 'comparações implícitas', será que é o mesmo que entendo por 'conversões de tipo explícitas' (/implicit type casting/)? Também não ſei ſe entendi o que você diße com 'retorno de reſultados ineſperados' — você quer dizer reſultado ou reação ao PoſtgreSQL ter dado reſultados ineſperados nas verſões anteriores? Mais importante, não entendi exatamente do que você discorda. É um fato que o PoſtgreSQL eſtá ficando mais eſtrito, de acordo com o padrão ISO SQL e com as boas práticas de programação, certo? > > Há algum tempo vi a documentação e me pareceu extremamente complicada. > > Revi agora: ou fiquei menos burro, ou está mais simples mesmo. Mesmo > > assim, não me pareceu prático o suficiente para uso generalizado; > > talvez eu precisasse dum bom tutorial para ser iluminado. > > > Sim, na verdade era bem mais complicado criar um tipo. A implementação > melhorou bastante. Que pena, continuo tão burro quanto antes então! ;-) > Exemplos de CREATE TYPE? No contrib está cheio de exemplos. Boa dica, obrigado. > Vale > ressaltar que a implementação CREATE TYPE do PostgreSQL não tem nada a > ver com a definida no ISO SQL (dá pra adivinhar o porquê, né?). Você quer dizer que a do ISO SQL é podre? Confeßo que não entendi direito http://savage.net.au/SQL/sql-2003-2.bnf.html#user-defined%20type%20body, mas de qualquer maneira BNF não é minha eſpecialidade. Pelo que vi o DB2 também é inconforme, implementando na verdade uma estrutura composta de 'n' atributos — mas achei intereßante que parte da sintaxe obrigatória do CREATE TYPE deles é MODE DB2SQL; será que ißo permitiria mais tarde um CREATE TYPE conforme ao ISO SQL? Talvez um mecanismo deßes foße-nos útil também. Ißo gera uma queſtão 'intereßante'… imagino que 'noßa' implementação ſeja mais antiga que a definição do padrão e até melhor, mas agora eſtamos inconformes — o que não é neceßariamente uma tragédia mas pode vir a dificultar migrações de outros ſiſtemas. > Leo, e sobre a criação de tipos base com CREATE TYPE. Como você quer > fazer a restrição (contenção)? cláusula INPUT fazendo a verificação > dentro da função foo_in()? Tirou a pergunta de minha boca. -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 5686 9607 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
