Re: bug? non working casts for domain

From: elein <elein(at)varlena(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bug? non working casts for domain
Date: 2006-05-08 18:15:04
Message-ID: 20060508181504.GG26910@varlena.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'll see what I can do about expanding my requirements/test
cases. Casting was not in my original test cases.
What else have I missed? Copy domain gripes to elein(at)varlena(dot)com(dot)

--elein
elein(at)varlena(dot)com

On Sat, May 06, 2006 at 10:19:39PM -0400, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > The error is coming from parse_expr.c::typecast_expression, and its call
> > to typenameTypeId(). I wish I understood how we do domains better to
> > fix this properly. Anyone?
>
> 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.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-05-08 18:19:54 Re: Number of dimensions of an array parameter
Previous Message Mark Wong 2006-05-08 18:12:01 Re: XLOG_BLCKSZ vs. wal_buffers table