bug? non working casts for domain
Dear PostgreSQL developer.
Although it is allowed to create a cast for a domain, it seems that there
is no way to trigger it. You can find attached an sql script to illustrate
the issue with postgresql 8.1.3. The create cast and create domain
documentations do not seem to discuss this point.
ISTM that it is a pg bug. Indeed, either
(1) the create cast should be rejected if it is not allowed for domains.
or
(2) the function should be triggered by explicit casts to the domain.
Have a nice day,
--
Fabien.
Attachments:
I can confirm that this is a bug. The attached SQL shows that creating
a CAST _to_ a domain type doesn't work, though the cast can be created.
The attached SQL provided by Fabien shows the failure.
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?
---------------------------------------------------------------------------
Fabien COELHO wrote:
Dear PostgreSQL developer.
Although it is allowed to create a cast for a domain, it seems that there
is no way to trigger it. You can find attached an sql script to illustrate
the issue with postgresql 8.1.3. The create cast and create domain
documentations do not seem to discuss this point.ISTM that it is a pg bug. Indeed, either
(1) the create cast should be rejected if it is not allowed for domains.
or
(2) the function should be triggered by explicit casts to the domain.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
Bruce Momjian <pgman@candle.pha.pa.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
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@varlena.com.
--elein
elein@varlena.com
Show quoted text
On Sat, May 06, 2006 at 10:19:39PM -0400, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.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?
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
Added to TODO list, with URL.
---------------------------------------------------------------------------
Fabien COELHO wrote:
Dear PostgreSQL developer.
Although it is allowed to create a cast for a domain, it seems that there
is no way to trigger it. You can find attached an sql script to illustrate
the issue with postgresql 8.1.3. The create cast and create domain
documentations do not seem to discuss this point.ISTM that it is a pg bug. Indeed, either
(1) the create cast should be rejected if it is not allowed for domains.
or
(2) the function should be triggered by explicit casts to the domain.
Have a nice day,
--
Fabien.
Content-Description:
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +