| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | 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-07 02:19:39 |
| Message-ID: | 17817.1146968379@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | James William Pye | 2006-05-07 02:27:09 | Re: pseudo-type record arguments for PL-functions |
| Previous Message | Tom Lane | 2006-05-07 01:53:46 | Re: pseudo-type record arguments for PL-functions |