----- Original Message -----
From: "Darren Duncan" <darren@darrenduncan.net>
To: "Jaime Casanova" <jaime@2ndquadrant.com>
Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Sent: Saturday, May 14, 2011 9:42 PM
Subject: Re: [HACKERS] DOMAINs and CASTs
> Jaime Casanova wrote:
>> If i create a DOMAIN an then want to create a CAST from that domain to
>> another type it gives an error.
>> Consider this example:
>> """
>> create domain datetime as timestamp with time zone
>> check (value between '1753-01-01 00:00:00' and '9999-12-31 23:59:59');
>>
>> create function datetime2int(datetime) returns int
>> language sql stable strict as $$
>> select $1::date - '1753-01-01'::date;
>> $$;
>>
>> create cast(datetime as int) with function datetime2int(datetime);
>> """
>>
>> if i try to cast, get this error:
>> select now()::datetime::int;
>> ERROR: cannot cast type datetime to integer
>>
>> The problem is that in find_coercion_pathway() the very first thing we
>> do is to get the base type of both: the source and target types. So,
>> the way to make it work is to create the function and the cast on the
>> base types.
>> But what if i create 2 domains on the same base types and want a
>> different behaviour on a cast to the same target type?
>
> I think that overloading the same cast syntax to get different behavior
> for different domains over the same base type is a bad idea.
>
> First of all, what if "cast(timestamp as int)" was already defined? Which
> cast then would you expect to be invoked here?
>
> '1800-01-01 00:00:00'::int
>
> ... the one for timestamp or the one for datetime?
>
> Second of all, what if you had 2 domains defined over timestamp and they
> overlapped and they both defined a cast as you did, with generic syntax?
> And you were casting a value in both domains as an int?
>
> I think it would be best that the generic cast syntax only be useable for
> casts defined on the base type, and if you want a domain-specific one you
> should use the function syntax such as your datetime2int().
>
> That way it is easier for users to predict what behavior will occur, and
> implementation will be easier too.
>
> -- Darren Duncan
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
