Re: bug? non working casts for domain

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

In response to

Browse pgsql-hackers by date

  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