From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Erik Jones" <ejones(at)engineyard(dot)com> |
Cc: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, "Bruce Momjian" <bruce(at)momjian(dot)us> |
Subject: | Re: lack of consequence with domains and types |
Date: | 2008-12-26 20:54:21 |
Message-ID: | b42b73150812261254n7c3ac8eaqa78d732b1819ff12@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Dec 24, 2008 at 6:41 PM, Erik Jones <ejones(at)engineyard(dot)com> wrote:
>
> On Dec 24, 2008, at 12:04 PM, Grzegorz Jaśkiewicz wrote:
>
>> On Wed, Dec 24, 2008 at 6:12 PM, Erik Jones <ejones(at)engineyard(dot)com> wrote:
>>>
>>> Yes, and columns have default values, too, which are not tied to their
>>> datatype's default value (if it even has one). ALTER TABLE initializes
>>> rows
>>> to have the new *column's* default. A column of some domain type could
>>> easily have some default other than the domain's default and, in fact, if
>>> you don't specify a default for the column then it's default is NULL.
>>
>> the whole thing about domains, is that you specify type and default,
>> and even check constraint. And I did specify default - hence I would
>> expect it to be set to that value!!
>
> You really need to understand the difference between a domain's default and
> a column's default. The ALTER TABLE docs specifically say that if you don't
> specify a default for the new *column* then that column is set to NULL for
> all rows. That is not the same as not providing a value for a column of
> some domain type with a default in an INSERT statement. A domain with a
> default does not specify that it can not be set to null:
I disagree. It's quite natural and reasonable to have defaults passed
through the composite type as the OP expects. This is a possible
improvement (TODO?) in the way composite types are handled. There are
a couple of other loopholes in domans/composite types:
* domains can't be stacked in an array (but you can if they are
wrapped in a composite type)
* check constraints not enforced for composite type on cast (but are
for domains)
* alter type should be expanded to allow things that are currently
possible via alter table (currently a TODO, IIRC), or create
table/alter table should be adjusted for better handling of types, and
'create type as' should be deprecated. The latter is what I think
should happen, but it's controversial :-).
In the meantime the OP has to decide what he wants to use more,
composite types or default values on domains.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Grzegorz Jaśkiewicz | 2008-12-26 20:57:04 | Re: lack of consequence with domains and types |
Previous Message | Grzegorz Jaśkiewicz | 2008-12-26 20:08:50 | Re: lack of consequence with domains and types |