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
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 |