From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: bug? non working casts for domain |
Date: | 2006-05-10 15:41:30 |
Message-ID: | Pine.LNX.4.64.0605101732160.15136@briare.cri.ensmp.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schaber | 2006-05-10 15:59:26 | Re: [HACKERS] Big IN() clauses etc : feature proposal |
Previous Message | Dennis Bjorklund | 2006-05-10 15:36:16 | Re: BEGIN inside transaction should be an error |