From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Domain casting still doesn't work right |
Date: | 2003-06-28 16:02:00 |
Message-ID: | 18176.1056816120@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Here's another example of domain casting not working right:
> create domain foo as varchar;
> select cast(x.y as foo) from (select 'foo') as x(y);
> ERROR: coerce_type: no conversion function from "unknown" to foo
Not the domain's fault. You get the same error without it:
regression=# select cast(x.y as varchar) from (select 'foo') as x(y);
ERROR: coerce_type: no conversion function from "unknown" to character varying
The problem, if it is one, is that the subselect's output column is
irrevocably assigned the datatype "unknown" when we form the subselect
result list. We could make this particular problem go away by coercing
the subselect result to text, but that would create problems in other
areas, notably UNIONs. In a UNION you need to leave the individual
subselect's outputs typed as unknown as long as possible, so that they
don't screw up a type assignment derived from another subselect where
the column isn't an untyped literal.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-06-28 16:15:57 | Re: .pot files are unavailable (?) |
Previous Message | The Hermit Hacker | 2003-06-28 16:00:54 | Re: Two weeks to feature freeze |