From b71189c2438e39154d68e3903f59c35d6d1d542c Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Tue, 9 Apr 2002 04:28:48 +0000 Subject: [PATCH] Remove TODO.detail domain file. --- doc/TODO.detail/domain | 142 ----------------------------------------- 1 file changed, 142 deletions(-) delete mode 100644 doc/TODO.detail/domain diff --git a/doc/TODO.detail/domain b/doc/TODO.detail/domain deleted file mode 100644 index 5bc4262e46..0000000000 --- a/doc/TODO.detail/domain +++ /dev/null @@ -1,142 +0,0 @@ -From pgsql-hackers-owner+M8916@postgresql.org Thu May 17 11:51:45 2001 -Return-path: -Received: from postgresql.org (webmail.postgresql.org [216.126.85.28]) - by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f4HFpid02613 - for ; Thu, 17 May 2001 11:51:44 -0400 (EDT) -Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28]) - by postgresql.org (8.11.3/8.11.1) with SMTP id f4HFoiA36759; - Thu, 17 May 2001 11:50:44 -0400 (EDT) - (envelope-from pgsql-hackers-owner+M8916@postgresql.org) -Received: from fred.plzen-city.cz (gate.plzen-city.cz [194.212.191.10]) - by postgresql.org (8.11.3/8.11.1) with ESMTP id f4HFMLA24019 - for ; Thu, 17 May 2001 11:22:21 -0400 (EDT) - (envelope-from horak@sit.plzen-city.cz) -Received: from exchange.mmp.plzen-city.cz ([192.168.4.42]) - by fred.plzen-city.cz (8.12.0.Beta7/8.12.0.Beta7/Wim) with ESMTP id f4HFMGoQ007660 - for ; Thu, 17 May 2001 17:22:16 +0200 -Subject: [HACKERS] possible DOMAIN implementation -MIME-Version: 1.0 -Content-Type: text/plain; - charset="iso-8859-2" -Content-Class: urn:content-classes:message -X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 -Date: Thu, 17 May 2001 17:22:05 +0200 -Message-ID: <9C8918CC8CDAAC4AA79D4594A480648901E68C2B@EXCHANGE.mmp.plzen-city.cz> -Thread-Topic: possible DOMAIN implementation -Thread-Index: AcDe5WK0+5JgskVMEdWdCQAQS2oI5Q== -From: =?iso-8859-2?Q?Hor=E1k_Daniel?= -To: -Content-Transfer-Encoding: 8bit -X-MIME-Autoconverted: from quoted-printable to 8bit by postgresql.org id f4HFMMA24022 -Precedence: bulk -Sender: pgsql-hackers-owner@postgresql.org -Status: OR - -Hello, - -I have spend some thinking about implementation of DOMAIN capability. -Here are my ideas. - -What is a domain? It is an alias for a type with size, constraints and -default values. It is like one column of a table. And this is the main -idea of my "implementation". It should be possible to implement it using -existing system tables. - -New rules for grammar can be easily created from already existing pieces -(column definition of a table). - -How to store information about a domain in system tables? -When a new domain is created it will: -- put a record into pg_type with typnam = domain name, new code for -typtype = 'd' and typrelid = oid of a new record in pg_class (next line) -- put a record into pg_class to create a fictional table with a new -relkind ('d'?), relnatts = 1, relname can be system generated -(pg_d_) -- put a records into pg_attribute and pg_attrdef with "column -(attribute) definition" - real type, size, default value etc., owner -will the fictional table from the previous step - -Then it will be required to modify functions that works with types. When -typtype of a retrieved type is 'd' then it will perform lookups into -pg_class, pg_attribute and pg_attrdef to find the real definition of the -domain. These additional lookups will also create a performace penalty -of using domains. But every feature has its costs. I know this paragraph -about the real implementation is very short, but I think there are -people that know the "type mechanism" better then I know. And can easier -tell if it is possible to go this way. - -I hope you understand my explanation. It is also possible that I don't -know some aspects of the backend code that makes my idea wrong. - - Dan - ----------------------------------------------- -Ing. Daniel Horak -network and system administrator -e-mail: horak@sit.plzen-city.cz -privat e-mail: dan.horak@email.cz ICQ:36448176 ----------------------------------------------- - ----------------------------(end of broadcast)--------------------------- -TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org - -From pgsql-hackers-owner+M8925@postgresql.org Thu May 17 14:04:29 2001 -Return-path: -Received: from postgresql.org (webmail.postgresql.org [216.126.85.28]) - by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f4HI4Sd12032 - for ; Thu, 17 May 2001 14:04:28 -0400 (EDT) -Received: from postgresql.org.org (webmail.postgresql.org [216.126.85.28]) - by postgresql.org (8.11.3/8.11.1) with SMTP id f4HI3hA18949; - Thu, 17 May 2001 14:03:43 -0400 (EDT) - (envelope-from pgsql-hackers-owner+M8925@postgresql.org) -Received: from sss.pgh.pa.us (sss.pgh.pa.us [216.151.103.158]) - by postgresql.org (8.11.3/8.11.1) with ESMTP id f4HHx4A16857 - for ; Thu, 17 May 2001 13:59:04 -0400 (EDT) - (envelope-from tgl@sss.pgh.pa.us) -Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) - by sss.pgh.pa.us (8.11.3/8.11.3) with ESMTP id f4HHwjR12171; - Thu, 17 May 2001 13:58:45 -0400 (EDT) -To: =?iso-8859-2?Q?Hor=E1k_Daniel?= -cc: pgsql-hackers@postgresql.org -Subject: Re: [HACKERS] possible DOMAIN implementation -In-Reply-To: <9C8918CC8CDAAC4AA79D4594A480648901E68C2B@EXCHANGE.mmp.plzen-city.cz> -References: <9C8918CC8CDAAC4AA79D4594A480648901E68C2B@EXCHANGE.mmp.plzen-city.cz> -Comments: In-reply-to =?iso-8859-2?Q?Hor=E1k_Daniel?= - message dated "Thu, 17 May 2001 17:22:05 +0200" -Date: Thu, 17 May 2001 13:58:45 -0400 -Message-ID: <12167.990122325@sss.pgh.pa.us> -From: Tom Lane -Precedence: bulk -Sender: pgsql-hackers-owner@postgresql.org -Status: OR - -=?iso-8859-2?Q?Hor=E1k_Daniel?= writes: -> When a new domain is created it will: -> - put a record into pg_type with typnam = domain name, new code for -> typtype = 'd' and typrelid = oid of a new record in pg_class (next line) -> - put a record into pg_class to create a fictional table with a new -> relkind ('d'?), relnatts = 1, relname can be system generated -> (pg_d_) - -Ugh. Don't overload pg_class with things that are not tables. I see no -reason that either pg_class or pg_attribute should be involved in the -definition of a domain. Make new system tables if you need to, but -don't confuse the semantics of critical tables. - -> - put a records into pg_attribute and pg_attrdef with "column -> (attribute) definition" - real type, size, default value etc., owner -> will the fictional table from the previous step - -> Then it will be required to modify functions that works with types. When -> typtype of a retrieved type is 'd' then it will perform lookups into -> pg_class, pg_attribute and pg_attrdef to find the real definition of the -> domain. These additional lookups will also create a performace penalty -> of using domains. - -Why shouldn't this info be directly available from the pg_type row? - - regards, tom lane - ----------------------------(end of broadcast)--------------------------- -TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -