Re: converting E'C:\\something' to bytea
| От | Tom Lane |
|---|---|
| Тема | Re: converting E'C:\\something' to bytea |
| Дата | |
| Msg-id | 16941.1300296573@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: converting E'C:\\something' to bytea (Vlad Romascanu <vromascanu@accurev.com>) |
| Ответы |
OT: Oleg Bartunov in Himalaya...
|
| Список | pgsql-general |
Vlad Romascanu <vromascanu@accurev.com> writes:
> Hi, Tom,
> Why does:
> CREATE CAST (text AS bytea) WITHOUT FUNCTION;
> SELECT E'C:\\something'::text::bytea;
> work as expected, but (with the original text->bytea cast in place):
> CREATE DOMAIN my_varlena AS text;
> CREATE CAST (my_varlena AS bytea) WITHOUT FUNCTION;
> SELECT E'C:\\something'::my_varlena::bytea;
> does not
Domains are not meant to support ad-hoc cast paths like that ---
generally, the parser smashes domains to their base types before even
looking into pg_cast. The reason for this is that the defined pathway
is source_domain -> source_base_type -> dest_base_type -> dest_domain
and allowing user-defined cast paths to short-circuit that would create
all kinds of uncertainty, in particular whether or not constraints on
a destination domain had been verified.
Possibly we ought to disallow CREATE CAST involving a domain, since
you're not the first person to think that he can impose special cast
rules by using a domain.
regards, tom lane
В списке pgsql-general по дате отправления: