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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-general by date

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