mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-21 08:29:39 +08:00
143 lines
6.7 KiB
Plaintext
143 lines
6.7 KiB
Plaintext
|
From pgsql-hackers-owner+M8916@postgresql.org Thu May 17 11:51:45 2001
|
||
|
|
Return-path: <pgsql-hackers-owner+M8916@postgresql.org>
|
||
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgreSQL.org>; 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 <pgsql-hackers@postgreSQL.org>; 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?= <horak@sit.plzen-city.cz>
|
||
|
|
To: <pgsql-hackers@postgresql.org>
|
||
|
|
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_<domainname>)
|
||
|
|
- 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: <pgsql-hackers-owner+M8925@postgresql.org>
|
||
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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?= <horak@sit.plzen-city.cz>
|
||
|
|
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?= <horak@sit.plzen-city.cz>
|
||
|
|
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 <tgl@sss.pgh.pa.us>
|
||
|
|
Precedence: bulk
|
||
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
||
|
|
Status: OR
|
||
|
|
|
||
|
|
=?iso-8859-2?Q?Hor=E1k_Daniel?= <horak@sit.plzen-city.cz> 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_<domainname>)
|
||
|
|
|
||
|
|
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
|
||
|
|
|