Re: [HACKERS] bug? non working casts for domain
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 EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] bug? non working casts for domain
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] bug? non working casts for domain
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 [EMAIL PROTECTED] --elein [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] bug? non working casts for domain
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
EnterpriseDBhttp://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);
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] bug? non working casts for domain
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
[HACKERS] 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.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);
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
