Re: lack of consequence with domains and types

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: lack of consequence with domains and types
Дата
Msg-id b42b73150812261254n7c3ac8eaqa78d732b1819ff12@mail.gmail.com
обсуждение исходный текст
Ответ на Re: lack of consequence with domains and types  (Erik Jones <ejones@engineyard.com>)
Список pgsql-general
On Wed, Dec 24, 2008 at 6:41 PM, Erik Jones <ejones@engineyard.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@engineyard.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

В списке pgsql-general по дате отправления:

Предыдущее
От: "Grzegorz Jaśkiewicz"
Дата:
Сообщение: Re: lack of consequence with domains and types
Следующее
От: "Grzegorz Jaśkiewicz"
Дата:
Сообщение: Re: lack of consequence with domains and types