Skip site navigation (1) Skip section navigation (2)

Re: lack of consequence with domains and types

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: lack of consequence with domains and types
Date: 2008-12-26 21:10:08
Message-ID: b42b73150812261310j5772529doe413712044ed2dc3@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-general
On Fri, Dec 26, 2008 at 3:57 PM, Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com> wrote:
> another glance at source code, and docs tells me - that there's not
> such thing as default value for custom type - unless that type is
> defined as new base scalar type. So probably, that would require
> postgresql to allow users to define default values for composite types
> as well, like that:
> create type foo AS
> (
>  a int default 1,
>  b foodomain default 'foo',
> ....
> );

don't forget, you can create types via create table:

create table foo as
(
  a int default 1,
  ...
  check (a<5)
);

create table bar(f foo);
insert into bar default values; -- should foo defaults fire?? I say
probably, but check constraints should definately be enforced
(currently they are not).

(since you can alter the table later, there is very little reason not
to create types with create table always).

merlin

In response to

pgsql-general by date

Next:From: Ivan Sergio BorgonovoDate: 2008-12-26 22:17:06
Subject: WITH AS vs subselect was: count (DISTINCT expression [ , ... ] ) and documentation
Previous:From: Grzegorz JaśkiewiczDate: 2008-12-26 20:57:04
Subject: Re: lack of consequence with domains and types

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group