Re: possible DOMAIN implementation
От | Tom Lane |
---|---|
Тема | Re: possible DOMAIN implementation |
Дата | |
Msg-id | 12167.990122325@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | possible DOMAIN implementation (Horák Daniel <horak@sit.plzen-city.cz>) |
Список | pgsql-hackers |
Horák 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
В списке pgsql-hackers по дате отправления: