DOMAINs and CASTs
Hi,
If i create a DOMAIN an then want to create a CAST from that domain to
another type it gives an error.
Consider this example:
"""
create domain datetime as timestamp with time zone
check (value between '1753-01-01 00:00:00' and '9999-12-31 23:59:59');
create function datetime2int(datetime) returns int
language sql stable strict as $$
select $1::date - '1753-01-01'::date;
$$;
create cast(datetime as int) with function datetime2int(datetime);
"""
if i try to cast, get this error:
select now()::datetime::int;
ERROR: cannot cast type datetime to integer
The problem is that in find_coercion_pathway() the very first thing we
do is to get the base type of both: the source and target types. So,
the way to make it work is to create the function and the cast on the
base types.
But what if i create 2 domains on the same base types and want a
different behaviour on a cast to the same target type?
ok, sounds odd... basic example datetime and smalldatetime types in ms
sql server... when casting to int the former give the number of days
since 1753-01-01 and the latter the number of days since 1900-01-01...
some systems i have seen (specially ERPs) tend to store dates as
number of days so there is a use case for this.
the fix for this doesn't look complicated (unless have missed
something), just try first with the types i receive and then with the
base types if they are domains... i'm not trying mixed situations: the
base type of the source and the target as we receive it and viceversa,
i think that's just complicating for a very little benefit if any...
attached (pass all regression tests), comments?
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
Attachments:
cast_domains.patchtext/x-patch; charset=US-ASCII; name=cast_domains.patchDownload
diff --git a/src/backend/parser/parse_coerce.c b/src/backend/parser/parse_coerce.c
index 0418972..7101499 100644
*** a/src/backend/parser/parse_coerce.c
--- b/src/backend/parser/parse_coerce.c
*************** find_coercion_pathway(Oid targetTypeId,
*** 1873,1885 ****
*funcid = InvalidOid;
! /* Perhaps the types are domains; if so, look at their base types */
! if (OidIsValid(sourceTypeId))
! sourceTypeId = getBaseType(sourceTypeId);
! if (OidIsValid(targetTypeId))
! targetTypeId = getBaseType(targetTypeId);
!
! /* Domains are always coercible to and from their base type */
if (sourceTypeId == targetTypeId)
return COERCION_PATH_RELABELTYPE;
--- 1873,1879 ----
*funcid = InvalidOid;
! /* If they are the same type will always be coercible */
if (sourceTypeId == targetTypeId)
return COERCION_PATH_RELABELTYPE;
*************** find_coercion_pathway(Oid targetTypeId,
*** 1888,1893 ****
--- 1882,1913 ----
ObjectIdGetDatum(sourceTypeId),
ObjectIdGetDatum(targetTypeId));
+ if (!HeapTupleIsValid(tuple))
+ {
+ Oid sourceBaseTypeId;
+ Oid targetBaseTypeId;
+
+ /* Perhaps the types are domains; if so, look at their base types */
+ if (OidIsValid(sourceTypeId))
+ sourceBaseTypeId = getBaseType(sourceTypeId);
+ if (OidIsValid(targetTypeId))
+ targetBaseTypeId = getBaseType(targetTypeId);
+
+ if ((sourceBaseTypeId != sourceTypeId) || (targetBaseTypeId != targetTypeId))
+ {
+ sourceTypeId = sourceBaseTypeId;
+ targetTypeId = targetBaseTypeId;
+
+ /* Domains are always coercible to and from their base type */
+ if (sourceTypeId == targetTypeId)
+ return COERCION_PATH_RELABELTYPE;
+
+ tuple = SearchSysCache2(CASTSOURCETARGET,
+ ObjectIdGetDatum(sourceTypeId),
+ ObjectIdGetDatum(targetTypeId));
+ }
+ }
+
if (HeapTupleIsValid(tuple))
{
Form_pg_cast castForm = (Form_pg_cast) GETSTRUCT(tuple);
Jaime Casanova <jaime@2ndquadrant.com> writes:
If i create a DOMAIN an then want to create a CAST from that domain to
another type it gives an error.
Yes. See previous discussions about that, e.g. these threads:
http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php
http://archives.postgresql.org/pgsql-hackers/2006-09/msg00695.php
It's *not* trivial to fix, at least not in a way that gives desirable
behavior for more than the simplest cases.
regards, tom lane
On Sat, May 14, 2011 at 5:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jaime Casanova <jaime@2ndquadrant.com> writes:
If i create a DOMAIN an then want to create a CAST from that domain to
another type it gives an error.It's *not* trivial to fix, at least not in a way that gives desirable
behavior for more than the simplest cases.
well, i'm just trying to manage the simplest case... do you think we
should manage other cases? what else should we do?
it's better to allows the creation of casts that are ignored?
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
Jaime Casanova wrote:
If i create a DOMAIN an then want to create a CAST from that domain to
another type it gives an error.
Consider this example:
"""
create domain datetime as timestamp with time zone
check (value between '1753-01-01 00:00:00' and '9999-12-31 23:59:59');create function datetime2int(datetime) returns int
language sql stable strict as $$
select $1::date - '1753-01-01'::date;
$$;create cast(datetime as int) with function datetime2int(datetime);
"""if i try to cast, get this error:
select now()::datetime::int;
ERROR: cannot cast type datetime to integerThe problem is that in find_coercion_pathway() the very first thing we
do is to get the base type of both: the source and target types. So,
the way to make it work is to create the function and the cast on the
base types.
But what if i create 2 domains on the same base types and want a
different behaviour on a cast to the same target type?
I think that overloading the same cast syntax to get different behavior for
different domains over the same base type is a bad idea.
First of all, what if "cast(timestamp as int)" was already defined? Which cast
then would you expect to be invoked here?
'1800-01-01 00:00:00'::int
... the one for timestamp or the one for datetime?
Second of all, what if you had 2 domains defined over timestamp and they
overlapped and they both defined a cast as you did, with generic syntax? And
you were casting a value in both domains as an int?
I think it would be best that the generic cast syntax only be useable for casts
defined on the base type, and if you want a domain-specific one you should use
the function syntax such as your datetime2int().
That way it is easier for users to predict what behavior will occur, and
implementation will be easier too.
-- Darren Duncan
Darren Duncan wrote:
I think it would be best that the generic cast syntax only be useable
for casts defined on the base type, and if you want a domain-specific
one you should use the function syntax such as your datetime2int().That way it is easier for users to predict what behavior will occur, and
implementation will be easier too.
Replying to myself, I offer another alternative:
What you ask for is indeed supported, but that if for a given input value more
than one cast applies to it, particularly for 2 overlapping domains, then which
cast is invoked is undefined, so for example the DBMS may just use the first one
it finds.
It is then up to the user to ensure that when they define casts over domains
that they just define ones that either produce the same outputs for the same
overlapping inputs (the best answer) or they ensure that they don't overlap in
their input domains.
-- Darren Duncan
----- Original Message -----
From: "Darren Duncan" <darren@darrenduncan.net>
To: "Jaime Casanova" <jaime@2ndquadrant.com>
Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Sent: Saturday, May 14, 2011 9:46 PM
Subject: Re: [HACKERS] DOMAINs and CASTs
Show quoted text
Darren Duncan wrote:
I think it would be best that the generic cast syntax only be useable for
casts defined on the base type, and if you want a domain-specific one you
should use the function syntax such as your datetime2int().That way it is easier for users to predict what behavior will occur, and
implementation will be easier too.Replying to myself, I offer another alternative:
What you ask for is indeed supported, but that if for a given input value
more than one cast applies to it, particularly for 2 overlapping domains,
then which cast is invoked is undefined, so for example the DBMS may just
use the first one it finds.It is then up to the user to ensure that when they define casts over
domains that they just define ones that either produce the same outputs
for the same overlapping inputs (the best answer) or they ensure that they
don't overlap in their input domains.-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, May 14, 2011 at 8:42 PM, Darren Duncan <darren@darrenduncan.net> wrote:
First of all, what if "cast(timestamp as int)" was already defined? Which
cast then would you expect to be invoked here?'1800-01-01 00:00:00'::int
i will expect an error in that case... what you're doing there is
casting an "unknown" to integer, for that to be valid you need an
intermediate cast to timestamp or in my case to datetime
... the one for timestamp or the one for datetime?
the one of the type i cast before cast to int; for example, "select
'1800-01-01 00:00:00'::timestamp with time zone::int" i expect the
cast of timestamp with time zone to int and in "select '1800-01-01
00:00:00'::datetime::int" the for datetime to int
Second of all, what if you had 2 domains defined over timestamp and they
overlapped and they both defined a cast as you did, with generic syntax?
And you were casting a value in both domains as an int?
i'm not following you, currently i only can define one cast (base type
of the domain to base type of target), but if i can create casts on
domains (and they worked) i can create different behaviours just
creating different functions for every domain and an specific cast for
that domain
I think it would be best that the generic cast syntax only be useable for
casts defined on the base type, and if you want a domain-specific one you
should use the function syntax such as your datetime2int().That way it is easier for users to predict what behavior will occur, and
implementation will be easier too.
really? how getting an error when i already have a cast on the domain
is predictable?
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
Jaime Casanova wrote:
On Sat, May 14, 2011 at 8:42 PM, Darren Duncan <darren@darrenduncan.net> wrote:
First of all, what if "cast(timestamp as int)" was already defined? Which
cast then would you expect to be invoked here?'1800-01-01 00:00:00'::int
i will expect an error in that case... what you're doing there is
casting an "unknown" to integer, for that to be valid you need an
intermediate cast to timestamp or in my case to datetime
Sorry, my bad; I meant to say (might be slightly misspelled):
('1800-01-01 00:00:00'::timestamp)::int
Now, since all values of a DOMAIN are also values of the base type the DOMAIN is
defined as being a subset of, then the sub-expression within the parenthesis
denotes a value that is both a timestamp and a datetime at the same time.
So, if a generic "CAST(timestamp as int)" is already defined, and you define a
"CAST(datetime as int)", then what should the above code (correct for
misspelling) do, or should it fail?
-- Darren Duncan
On Sun, May 15, 2011 at 2:13 AM, Darren Duncan <darren@darrenduncan.net> wrote:
('1800-01-01 00:00:00'::timestamp)::int
Now, since all values of a DOMAIN are also values of the base type the
DOMAIN is defined as being a subset of, then the sub-expression within the
parenthesis denotes a value that is both a timestamp and a datetime at the
same time.So, if a generic "CAST(timestamp as int)" is already defined, and you define
a "CAST(datetime as int)", then what should the above code (correct for
misspelling) do, or should it fail?
Obviously it should run the cast from timestamp to int, why it will
run a cast from a domain?
the other way should be allowed, though... a cast from datetime to int
should first look for cast function using the domain and if it don't
find it then with base type
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
On Sun, May 15, 2011 at 3:26 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
Obviously it should run the cast from timestamp to int, why it will
run a cast from a domain?
So let's think about some harder scenarios.
Given two types T1 and T2, and two domains D1 over T1 and D2 over T2,
and a cast from a value of type D1 to type D2, then:
(1) If there is an implicit cast from D1 to D2 and an implicit cast
from T1 to T2, then presumably we should use the cast from D1 to D2,
since it's more specific. Or if none of the available casts involve
domains, but there is a cast of some sort from T1 to T2, then it seems
clear to use that one. But what if we instead have a cast from D1 to
T2 and a cast from T1 to D2? Which one should we prefer? Why?
(2) What happens if there are casts T1 -> T2 and D1 -> D2, but the D1
-> D2 cast is explicit, while the T1 -> T2 cast is on-assignment?
Should we use the D1->D2 cast when the context is explicit and the
T1->T2 when the context is on-assignment? That seems confusing.
Alternatively, we could decide that the on-assignment cast always
beats the explicit cast, even in an explicit-cast context. But that
amounts to ignoring the D1->D2 cast altogether - is that what we want?
(3) What happens if one or both of T1 or T2 are themselves domains
over some other types T3 and T4, respectively? Now there are nine
possible pairings of types (any of D1, T1, T3 with any of D2, T2, T4)
and in each case the available cast could have one of three contexts.
How do we decide which cast wins? Also, we might now need 9 probes
into pg_cast to find all the relevant casts, whereas the current code
needs just one - even in the previous scenario, we might need 4 probes
instead of one. That'll be slower - is it worth it? What's the
performance penalty in an artificially constructed worst case?
(4) What happens if T1 is a domain over T2? Then we have another
option - cast D1 to D2 by smashing it to its base type twice (first to
T1, then to T2), and the re-applying any domain constraint on D2. Is
that preferable to applying a cast from D1 to T1 and then casting to
D2? Is it preferable to applying a cast from D1 to T2 and then
re-applying the domain constraint on D2? Is it preferable to a cast
directly from D1 to D2? And in each case, does the context of the
cast matter?
I'm not throwing these questions out to be flip or to make life
difficult - I'm just saying they need to be thought about, and the
answers don't seem obvious (to me).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Sun, May 15, 2011 at 1:53 PM, Robert Haas <robertmhaas@gmail.com> wrote:
So let's think about some harder scenarios.
Given two types T1 and T2, and two domains D1 over T1 and D2 over T2,
and a cast from a value of type D1 to type D2, then:
ok. a few fair questions, thanks
(1) If there is an implicit cast from D1 to D2 and an implicit cast
from T1 to T2, then presumably we should use the cast from D1 to D2,
since it's more specific. Or if none of the available casts involve
domains, but there is a cast of some sort from T1 to T2, then it seems
clear to use that one. But what if we instead have a cast from D1 to
T2 and a cast from T1 to D2? Which one should we prefer? Why?
ok, this is the specific problem i said not to touch in my patch...
but, IMHO, we should use T1->D2 on the base that that is the final
type the user wants...
(2) What happens if there are casts T1 -> T2 and D1 -> D2, but the D1
-> D2 cast is explicit, while the T1 -> T2 cast is on-assignment?
Should we use the D1->D2 cast when the context is explicit and the
T1->T2 when the context is on-assignment? That seems confusing.
Alternatively, we could decide that the on-assignment cast always
beats the explicit cast, even in an explicit-cast context. But that
amounts to ignoring the D1->D2 cast altogether - is that what we want?
confusing yes. still, imho, we should use the casts based on context
as we always do...
(3) What happens if one or both of T1 or T2 are themselves domains
over some other types T3 and T4, respectively? Now there are nine
possible pairings of types (any of D1, T1, T3 with any of D2, T2, T4)
and in each case the available cast could have one of three contexts.
How do we decide which cast wins? Also, we might now need 9 probes
into pg_cast to find all the relevant casts, whereas the current code
needs just one - even in the previous scenario, we might need 4 probes
instead of one. That'll be slower - is it worth it? What's the
performance penalty in an artificially constructed worst case?(4) What happens if T1 is a domain over T2? Then we have another
option - cast D1 to D2 by smashing it to its base type twice (first to
T1, then to T2), and the re-applying any domain constraint on D2. Is
that preferable to applying a cast from D1 to T1 and then casting to
D2? Is it preferable to applying a cast from D1 to T2 and then
re-applying the domain constraint on D2? Is it preferable to a cast
directly from D1 to D2? And in each case, does the context of the
cast matter?
these two are very good questions and i can't see a "right" answer for them
I'm not throwing these questions out to be flip or to make life
difficult - I'm just saying they need to be thought about, and the
answers don't seem obvious (to me).
still, we have a problem... because we are happily ignoring correctely
created casts...
at least, we should document that casts on domains are ignored and
that we should use the base types instead, maybe even a warning or a
notice when issuing the CREATE CAST command using domains...
make the user think everything is fine when it's not is not a good idea
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
On Sun, May 15, 2011 at 7:43 PM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
still, we have a problem... because we are happily ignoring correctely
created casts...
at least, we should document that casts on domains are ignored and
that we should use the base types instead, maybe even a warning or a
notice when issuing the CREATE CAST command using domains...make the user think everything is fine when it's not is not a good idea
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Sun, May 15, 2011 at 9:01 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Sun, May 15, 2011 at 7:43 PM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
still, we have a problem... because we are happily ignoring correctely
created casts...
at least, we should document that casts on domains are ignored and
that we should use the base types instead, maybe even a warning or a
notice when issuing the CREATE CAST command using domains...make the user think everything is fine when it's not is not a good idea
+1.
ok, i will make a patch for this... btw, why is that we allow to
create those casts at all? or we can deny them?
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
On Sun, May 15, 2011 at 10:13 PM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
On Sun, May 15, 2011 at 9:01 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Sun, May 15, 2011 at 7:43 PM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
still, we have a problem... because we are happily ignoring correctely
created casts...
at least, we should document that casts on domains are ignored and
that we should use the base types instead, maybe even a warning or a
notice when issuing the CREATE CAST command using domains...make the user think everything is fine when it's not is not a good idea
+1.
ok, i will make a patch for this... btw, why is that we allow to
create those casts at all? or we can deny them?
Before you write the patch... we should probably try to agree on which
of the various options you mention makes most sense.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Sun, May 15, 2011 at 9:14 PM, Robert Haas <robertmhaas@gmail.com> wrote:
we should probably try to agree on which
of the various options you mention makes most sense.
well... my original patch only handle the simplest case, namely, try
to make the cast that the user wants and if none is defined fall to
the base types...
anything else will complicate things as you shown... actually, things
looks very simple until we start creating trees of domains...
what options look sane to you?
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
Jaime Casanova wrote:
On Sun, May 15, 2011 at 9:14 PM, Robert Haas <robertmhaas@gmail.com> wrote:
we should probably try to agree on which
of the various options you mention makes most sense.well... my original patch only handle the simplest case, namely, try
to make the cast that the user wants and if none is defined fall to
the base types...anything else will complicate things as you shown... actually, things
looks very simple until we start creating trees of domains...
what options look sane to you?
The sanest option I see is don't overload the CAST syntax for subtypes. Just
call the foo2bar() function instead. You still get code with the same level of
terseness and that is just as easy to read and understand, and there is no
question of semantics. Also, that solution works right now. -- Darren Duncan
On Tue, May 17, 2011 at 12:29 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
On Sun, May 15, 2011 at 9:14 PM, Robert Haas <robertmhaas@gmail.com> wrote:
we should probably try to agree on which
of the various options you mention makes most sense.well... my original patch only handle the simplest case, namely, try
to make the cast that the user wants and if none is defined fall to
the base types...anything else will complicate things as you shown... actually, things
looks very simple until we start creating trees of domains...
what options look sane to you?
Well, clearly we should document.
The more controversial question is what to do if someone tries to
create such a cast anyway. We could just ignore that as we do now, or
we could throw a NOTICE, WARNING, or ERROR. A NOTICE or WARNING has
the disadvantage that the client might ignore it, and the user be
unaware. An ERROR has the disadvantage that a dump-and-reload from an
earlier version of PostgreSQL might fail - which also means that
pg_upgrade will fail - after the point at which it's disabled the old
cluster. I'm not sure how seriously to take that risk, but it's
something to think about.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:
The more controversial question is what to do if someone tries to
create such a cast anyway. We could just ignore that as we do now, or
we could throw a NOTICE, WARNING, or ERROR.
IMHO, not being an error per se but an implementation limitation i
would prefer to send a WARNING
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
On Tue, May 17, 2011 at 3:11 PM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:
The more controversial question is what to do if someone tries to
create such a cast anyway. We could just ignore that as we do now, or
we could throw a NOTICE, WARNING, or ERROR.IMHO, not being an error per se but an implementation limitation i
would prefer to send a WARNING
OK, I'm not hearing any objections...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:
The more controversial question is what to do if someone tries to
create such a cast anyway. We could just ignore that as we do now, or
we could throw a NOTICE, WARNING, or ERROR.IMHO, not being an error per se but an implementation limitation i
would prefer to send a WARNING
Implementation limitations are normally reported as errors. I don't see
why it should be different here.
It's debatable whether it's an implementation restriction anyway. If
you want to create casts from or to a domain, maybe distinct types or
type aliases or something like that would be a more appropriate feature
in the long run.
On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:
The more controversial question is what to do if someone tries to
create such a cast anyway. We could just ignore that as we do now, or
we could throw a NOTICE, WARNING, or ERROR.IMHO, not being an error per se but an implementation limitation i
would prefer to send a WARNINGImplementation limitations are normally reported as errors. I don't see
why it should be different here.
ok, patch reports an error... do we want to backpatch this? if we want
to do so maybe we can backpatch as a warning
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Attachments:
casts_on_domains.patchtext/x-patch; charset=US-ASCII; name=casts_on_domains.patchDownload
diff --git a/src/backend/commands/functioncmds.c b/src/backend/commands/functioncmds.c
index 03da168..a29c13c 100644
--- a/src/backend/commands/functioncmds.c
+++ b/src/backend/commands/functioncmds.c
@@ -1517,6 +1517,17 @@ CreateCast(CreateCastStmt *stmt)
errmsg("target data type %s is a pseudo-type",
TypeNameToString(stmt->targettype))));
+ /* no domains allowd */
+ if (sourcetyptype == TYPTYPE_DOMAIN)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("casts over domains are not implemented yet")));
+
+ if (targettyptype == TYPTYPE_DOMAIN)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("casts over domains are not implemented yet")));
+
/* Permission check */
if (!pg_type_ownercheck(sourcetypeid, GetUserId())
&& !pg_type_ownercheck(targettypeid, GetUserId()))
@@ -1672,11 +1683,13 @@ CreateCast(CreateCastStmt *stmt)
* etc. would have to be modified to look through domains to their
* base types.
*/
+#ifdef NOT_USED
if (sourcetyptype == TYPTYPE_DOMAIN ||
targettyptype == TYPTYPE_DOMAIN)
ereport(ERROR,
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
errmsg("domain data types must not be marked binary-compatible")));
+#endif
}
/*
On Mon, Jun 13, 2011 at 4:39 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:
The more controversial question is what to do if someone tries to
create such a cast anyway. We could just ignore that as we do now, or
we could throw a NOTICE, WARNING, or ERROR.IMHO, not being an error per se but an implementation limitation i
would prefer to send a WARNINGImplementation limitations are normally reported as errors. I don't see
why it should be different here.ok, patch reports an error... do we want to backpatch this? if we want
to do so maybe we can backpatch as a warning
I'm not even really sure I want an ERROR anywhere. If it weren't
something we have accepted previously, I'd be all in favor, but I'm
unconvinced it's worth breaking people's dumps over this.
As far as the back-branches go, I'd be inclined to back-patch only a doc fix.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote:
On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:
The more controversial question is what to do if someone tries to
create such a cast anyway. �We could just ignore that as we do now, or
we could throw a NOTICE, WARNING, or ERROR.IMHO, not being an error per se but an implementation limitation i
would prefer to send a WARNINGImplementation limitations are normally reported as errors. �I don't see
why it should be different here.ok, patch reports an error... do we want to backpatch this? if we want
to do so maybe we can backpatch as a warning
Minor clarification attached.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
Attachments:
casts_on_domains_02.patchtext/plain; charset=us-asciiDownload
diff --git a/src/backend/commands/functioncmds.c b/src/backend/commands/functioncmds.c
index 03da168..a29c13c 100644
--- a/src/backend/commands/functioncmds.c
+++ b/src/backend/commands/functioncmds.c
@@ -1517,6 +1517,17 @@ CreateCast(CreateCastStmt *stmt)
errmsg("target data type %s is a pseudo-type",
TypeNameToString(stmt->targettype))));
+ /* no domains allowd */
+ if (sourcetyptype == TYPTYPE_DOMAIN)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("casts from domains are not implemented yet")));
+
+ if (targettyptype == TYPTYPE_DOMAIN)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("casts to domains are not implemented yet")));
+
/* Permission check */
if (!pg_type_ownercheck(sourcetypeid, GetUserId())
&& !pg_type_ownercheck(targettypeid, GetUserId()))
@@ -1672,11 +1683,13 @@ CreateCast(CreateCastStmt *stmt)
* etc. would have to be modified to look through domains to their
* base types.
*/
+#ifdef NOT_USED
if (sourcetyptype == TYPTYPE_DOMAIN ||
targettyptype == TYPTYPE_DOMAIN)
ereport(ERROR,
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
errmsg("domain data types must not be marked binary-compatible")));
+#endif
}
/*
Where are we on this?
---------------------------------------------------------------------------
David Fetter wrote:
On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote:
On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:
The more controversial question is what to do if someone tries to
create such a cast anyway. ?We could just ignore that as we do now, or
we could throw a NOTICE, WARNING, or ERROR.IMHO, not being an error per se but an implementation limitation i
would prefer to send a WARNINGImplementation limitations are normally reported as errors. ?I don't see
why it should be different here.ok, patch reports an error... do we want to backpatch this? if we want
to do so maybe we can backpatch as a warningMinor clarification attached.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.icsRemember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
[ Attachment, skipping... ]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Fri, Oct 14, 2011 at 3:19 PM, Bruce Momjian <bruce@momjian.us> wrote:
Where are we on this?
Well, I don't know. We had a couple of different ideas on what to do
about it, and I'm not sure anyone was completely in love with any of
the available options.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
David Fetter wrote:
On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote:
On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:
The more controversial question is what to do if someone tries to
create such a cast anyway. ?We could just ignore that as we do now, or
we could throw a NOTICE, WARNING, or ERROR.IMHO, not being an error per se but an implementation limitation i
would prefer to send a WARNINGImplementation limitations are normally reported as errors. ?I don't see
why it should be different here.ok, patch reports an error... do we want to backpatch this? if we want
to do so maybe we can backpatch as a warningMinor clarification attached.
What happened to this patch for casts on domains from June?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
/rtmp/casts_on_domains_02.patchtext/x-diffDownload
diff --git a/src/backend/commands/functioncmds.c b/src/backend/commands/functioncmds.c
index 03da168..a29c13c 100644
--- a/src/backend/commands/functioncmds.c
+++ b/src/backend/commands/functioncmds.c
@@ -1517,6 +1517,17 @@ CreateCast(CreateCastStmt *stmt)
errmsg("target data type %s is a pseudo-type",
TypeNameToString(stmt->targettype))));
+ /* no domains allowd */
+ if (sourcetyptype == TYPTYPE_DOMAIN)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("casts from domains are not implemented yet")));
+
+ if (targettyptype == TYPTYPE_DOMAIN)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("casts to domains are not implemented yet")));
+
/* Permission check */
if (!pg_type_ownercheck(sourcetypeid, GetUserId())
&& !pg_type_ownercheck(targettypeid, GetUserId()))
@@ -1672,11 +1683,13 @@ CreateCast(CreateCastStmt *stmt)
* etc. would have to be modified to look through domains to their
* base types.
*/
+#ifdef NOT_USED
if (sourcetyptype == TYPTYPE_DOMAIN ||
targettyptype == TYPTYPE_DOMAIN)
ereport(ERROR,
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
errmsg("domain data types must not be marked binary-compatible")));
+#endif
}
/*
On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian <bruce@momjian.us> wrote:
David Fetter wrote:
On Mon, Jun 13, 2011 at 03:39:39AM -0500, Jaime Casanova wrote:
On Mon, Jun 6, 2011 at 6:36 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On tis, 2011-05-17 at 14:11 -0500, Jaime Casanova wrote:
On Tue, May 17, 2011 at 12:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:
The more controversial question is what to do if someone tries to
create such a cast anyway. ?We could just ignore that as we do now, or
we could throw a NOTICE, WARNING, or ERROR.IMHO, not being an error per se but an implementation limitation i
would prefer to send a WARNINGImplementation limitations are normally reported as errors. ?I don't see
why it should be different here.ok, patch reports an error... do we want to backpatch this? if we want
to do so maybe we can backpatch as a warningMinor clarification attached.
What happened to this patch for casts on domains from June?
Well, if we apply this, it has the possibility to break existing
dumps. I think at a minimum if we're going to do this we need to also
modify pg_dump not to dump any such useless casts that may exist in
pre-9.2 databases, so that our usual advice to use the newer pg_dump
will still work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian <bruce@momjian.us> wrote:
What happened to this patch for casts on domains from June?
Well, if we apply this, it has the possibility to break existing
dumps.
There's also the question of whether there's really much point.
The whole question of what to do with casts on domains is hard,
and I didn't think that thread made any progress towards defining
better behavior. I'd just as soon leave things alone until we
have an idea of what would be better.
regards, tom lane
Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Mon, Nov 28, 2011 at 9:46 PM, Bruce Momjian <bruce@momjian.us> wrote:
What happened to this patch for casts on domains from June?
Well, if we apply this, it has the possibility to break existing
dumps.There's also the question of whether there's really much point.
The whole question of what to do with casts on domains is hard,
and I didn't think that thread made any progress towards defining
better behavior. I'd just as soon leave things alone until we
have an idea of what would be better.
OK, fine. That conclusion was not made in the original thread.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes:
Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
Well, if we apply this, it has the possibility to break existing
dumps.
BTW, it occurs to me that we could dodge that objection, with much less
work than Robert suggests, if we just made the message be a WARNING not
an ERROR. I think that'd do just as well in terms of what the message
could usefully accomplish, ie, steer people away from doing things that
won't work. Still not sure that it's worth doing though,
regards, tom lane
On Tue, Nov 29, 2011 at 10:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Bruce Momjian <bruce@momjian.us> writes:
Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
Well, if we apply this, it has the possibility to break existing
dumps.BTW, it occurs to me that we could dodge that objection, with much less
work than Robert suggests, if we just made the message be a WARNING not
an ERROR. I think that'd do just as well in terms of what the message
could usefully accomplish, ie, steer people away from doing things that
won't work. Still not sure that it's worth doing though,
i'm fine with a WARNING
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
On Tue, Nov 29, 2011 at 11:11 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
On Tue, Nov 29, 2011 at 10:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Bruce Momjian <bruce@momjian.us> writes:
Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
Well, if we apply this, it has the possibility to break existing
dumps.BTW, it occurs to me that we could dodge that objection, with much less
work than Robert suggests, if we just made the message be a WARNING not
an ERROR. I think that'd do just as well in terms of what the message
could usefully accomplish, ie, steer people away from doing things that
won't work. Still not sure that it's worth doing though,i'm fine with a WARNING
Me too; I suggested it before (so did you).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Nov 29, 2011 at 10:12 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Nov 29, 2011 at 11:11 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
On Tue, Nov 29, 2011 at 10:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Bruce Momjian <bruce@momjian.us> writes:
Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
Well, if we apply this, it has the possibility to break existing
dumps.BTW, it occurs to me that we could dodge that objection, with much less
work than Robert suggests, if we just made the message be a WARNING not
an ERROR. I think that'd do just as well in terms of what the message
could usefully accomplish, ie, steer people away from doing things that
won't work. Still not sure that it's worth doing though,i'm fine with a WARNING
Me too; I suggested it before (so did you).
are we going to put this warning in this release?
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
On Tue, Apr 24, 2012 at 3:00 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
are we going to put this warning in this release?
Done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company