Re: lack of consequence with domains and types

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

In response to

Browse pgsql-general by date

  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