2015-11-23 15:58 GMT-02:00 Sebastian Webber <sebast...@swebber.me>: > > Meu caro Dutra, segundo a doc[1], dá pra dizer que: > > CREATE DOMAIN creates a new domain. A domain is essentially a data type with > optional constraints (restrictions on the allowed set of values) ...
Então, mais ou menos… esse é um ponto em que nossa documentação comete um erro conceitual grosseiro. > Domains are useful for abstracting common constraints on fields into a > single location for maintenance. Perfeito, mas não apenas. O DOMAIN do SQL, que o PostgreSQL segue, não é domínio de verdade. Creio que já (tentei) explicar isso aqui antes, mas como é um dos meus assuntos favoritos, tentarei de novo: Um domínio é uma lista de valores — conceitualmente, porque podem ser valores contínuos (não discretos), caso em que a lista não pode ser realizada; idem para domínios infinitos. Um tipo de dados é um domínio e seus operadores. Por exemplo, no caso ‘em tela’ (jargão aqui de Brasília), um CPF é um número de até onze caracteres, ou precisamente onze se o precedermos de zeros. Até onde eu saiba; perdoem alguma imprecisão no exemplo. O domínio CPF é constituído de todos os números de CPF válidos. Como apenas os nove números excluindo os dois dígitos verificadores à direita são relevantes para gerar a lista, podemos dizer que o domínio, a princípio, seria de 1 a 999.999.999, concatenados com os respectivos dígitos verificadores. No caso, suponho que 0 seja um caso especial, ou seja, que não haja um CPF 0-XX onde XX seriam os DVs correspondentes a 0. Já o tipo de dados seriam os operadores correspondentes. Não consigo imaginar, de bate-pronto, algum operador que não seja o de identidade (comparação para ver se é igual ou diferente); por exemplo, não me parece fazer sentido querer concatenar, cortar, somar, subtrair, multiplicar, dividir, comparar se maior ou menos &c. Talvez operadores para extrair os dígitos significativos (os nove excetuando os DVs) e os dígitos verificadores. O interessante a reter é que não faz sentido operar num determinado domínio com operadores que não correspondam ao tipo. Portanto, por definição, uma definição de domínio tem de excluir operações de outros tipos (por exemplo, concatenar ou multiplicar CPFs), ou que envolvam outros domínios sem que sejam operações especificamente previstas para o domínio em questão e outro domínio qualuqer (por exemplo, concatenar um CPF com um CNPJ, ou multiplicar um CPF por um CNPJ). Até onde já li e testei, um DOMAIN SQL não impede isso. Teste; deve ser possível CREATE TABLE cpf (cpf AS cpf); com esse DOMAIN, e fazer um SELECT cpf * 2 FROM cpf;, o que não seria possível com um domínio de verdade. Aproveitando para bater noutra tecla que me é cara, é por causa desse tipo de problema de confusão conceitual (embora não desse problema específico) que o SQL não é relacional: para começo de conversa, uma tabela SQL não necessariamente é uma relação (que precisa de ao menos uma chave natural), mas pode ser um saco (sem chave natural, ou seja, não é um conjunto). > For example, several tables might contain > email address columns, all requiring the same CHECK constraint to verify the > address syntax. Define a domain rather than setting up each table's > constraint individually. Ou seja, é útil mesmo sem ser um domínio: é um atalho para declarar uma restrição de validação. > Chamamos isso de empate técnico? :D > > [1] http://www.postgresql.org/docs/current/static/sql-createdomain.htm Posso dizer que não é uma disputa, portanto não faz sentido falar em empate? ;-) -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691 ICQ/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
