Fw: [HACKERS] DOMAINs and CASTs

2011-05-14 Thread Gelman


- Original Message - 
From: Darren Duncan dar...@darrenduncan.net

To: Jaime Casanova ja...@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 '-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 



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Fw: [HACKERS] DOMAINs and CASTs

2011-05-14 Thread Gelman


- Original Message - 
From: Jaime Casanova ja...@2ndquadrant.com

To: Tom Lane t...@sss.pgh.pa.us
Cc: PostgreSQL-development pgsql-hackers@postgresql.org
Sent: Saturday, May 14, 2011 8:29 PM
Subject: Re: [HACKERS] DOMAINs and CASTs


On Sat, May 14, 2011 at 5:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:

Jaime Casanova ja...@2ndquadrant.com writes:

If i create a DOMAIN an then want to create a CAST from that domain to
another type it gives an error.


It's *not* trivial to fix, at least not in a way that gives desirable
behavior for more than the simplest cases.



well, i'm just trying to manage the simplest case... do you think we
should manage other cases? what else should we do?
it's better to allows the creation of casts that are ignored?

--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitaciĆ³n de PostgreSQL

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers 



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers