Thread: 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.
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. + DROP DOMAIN a_year CASCADE; -- a simple domain CREATE DOMAIN a_year AS INTEGER CHECK (VALUE BETWEEN 1 AND 3000); -- ok SELECT 1::a_year; SELECT CAST('2000' AS a_year); -- fails as expected SELECT 0::a_year; CREATE FUNCTION date2year(DATE) RETURNS a_year IMMUTABLE STRICT AS $$ SELECT EXTRACT(YEAR FROM $1)::a_year; $$ LANGUAGE sql; -- ok SELECT date2year(CURRENT_DATE); -- fails as expected SELECT date2year(DATE '3001-01-01'); CREATE CAST (DATE AS a_year) WITH FUNCTION date2year(DATE); -- fails, I would expect 1970 SELECT (DATE '1970-03-20')::a_year; -- fails, I would expect the current year SELECT CURRENT_DATE::a_year; SELECT CAST(CURRENT_DATE AS a_year);
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 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? > > http://www.postgresql.org/docs/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? > > http://archives.postgresql.org -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +