Re: bug? non working casts for domain - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: bug? non working casts for domain
Date
Msg-id Pine.LNX.4.64.0605101732160.15136@briare.cri.ensmp.fr
Whole thread Raw
In response to Re: bug? non working casts for domain  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> The reason the cast isn't found is that find_coercion_pathway() strips
> off the domains before it ever even looks in pg_cast.  We can't simply
> remove that logic without breaking things (notably, the ability to cast
> between a domain and its base type).  I think it would be a mistake to
> consider this behavior in isolation anyway --- it's fairly tightly tied
> to the way that domains are handled (or, mostly, ignored) in
> operator/function lookup.  See recent gripes from Elein.
>
> If someone can put together a coherent proposal for how domains should
> be dealt with in operator/function resolution, I'm all ears.

I would expect a DOMAIN to be a real plain type, and to have cast to 
and/or from its base type automatically created? The send/receive/in/out 
and so functions could be taken from the base type. All types could have a 
"check" function called on some occasions (well, each time one value is 
defined) when available to check for the validity of the value wrt the 
contraints, and that would be used by domains? If you do that, create
domain is just an alias for create type, and there is nothing special
about them one they are created.

But I think that it is maybe a little too simplistic and does not address 
the all relevant internal issues...

-- 
Fabien


pgsql-hackers by date:

Previous
From: Markus Schaber
Date:
Subject: Re: [PERFORM] Big IN() clauses etc : feature proposal
Next
From: Nis Jorgensen
Date:
Subject: Re: [PERFORM] Big IN() clauses etc : feature proposal