Re: DOMAINs and CASTs
От | Darren Duncan |
---|---|
Тема | Re: DOMAINs and CASTs |
Дата | |
Msg-id | 4DCF2F81.3010608@darrenduncan.net обсуждение исходный текст |
Ответ на | DOMAINs and CASTs (Jaime Casanova <jaime@2ndquadrant.com>) |
Ответы |
Re: DOMAINs and CASTs
Re: DOMAINs and CASTs |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: