Thread: 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
Attachment
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 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? 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 > 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 WARNING > > Implementation 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
Attachment
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 WARNING >> >> Implementation 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 WARNING > > > > Implementation 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
Attachment
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 WARNING > > > > > > Implementation 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 [ 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 WARNING > > > > > > Implementation 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. 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. + 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 WARNING >> > > >> > > Implementation 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. > > 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