Re: [PATCHES] int4 <-> bool casts
Peter Eisentraut <[EMAIL PROTECTED]> writes: > I believe I would have objected to an int/bool cast. I do so now > anyway. This was already discussed and agreed to. Since it's an explicit-only cast, I see no harm in it. And it's certainly been requested often enough. > - Casting back and forth does not preserve information. (This may be > true for some other type pairs as well, but in this case it's true in > almost every instance.) On those grounds we should disallow most of the numeric-category casts. > - It's an arbitary definition that is not obviously supported by > mathematical or similar principles. Nonetheless, the convention 0=false, 1=true is widely recognized. > - It opens the door for other silly casts like empty string => false, > non-empty string => true. I haven't seen any requests for any such casts. This cast is responding to market demand, no more. > - It's unnecessary because you can express the same thing using other > expressions that clearly state what they do. Basically what this is for is building in a feature that people otherwise build for themselves. On the grounds of "it's unnecessary" we could throw away large chunks of Postgres :-) regards, tom lane ---(end of broadcast)--- TIP 3: 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: [PATCHES] int4 <-> bool casts
Neil Conway wrote: > It has a long standing precedent outside of mathematics, such as in C > and derived programming languages. C doesn't have a boolean type. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] int4 <-> bool casts
Neil Conway wrote: > Peter Eisentraut wrote: > > That email message is about a timestamp data type. > > Hmm, it seems that when Bruce removes items from the patch queue, the > remaining items are renumbered. You can find the original thread here: > > http://archives.postgresql.org/pgsql-patches/2004-10/msg00140.php Oh, sorry, yea, that does happen. I would just shoot him the subject line and the URL for the patches queue. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] int4 <-> bool casts
Neil Conway wrote: > I've applied a modified version of this patch from seanc: > > http://candle.pha.pa.us/mhonarc/patches2/msg00029.html > > (Sorry, I've lost the original thread.) The patch as I applied it is > attached. Catalog version bumped. That email message is about a timestamp data type. I believe I would have objected to an int/bool cast. I do so now anyway. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] int4 <-> bool casts
Peter Eisentraut wrote: That email message is about a timestamp data type. Hmm, it seems that when Bruce removes items from the patch queue, the remaining items are renumbered. You can find the original thread here: http://archives.postgresql.org/pgsql-patches/2004-10/msg00140.php I believe I would have objected to an int/bool cast. I do so now anyway. On what grounds? -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] int4 <-> bool casts
Neil Conway wrote: > > I believe I would have objected to an int/bool cast. I do so now > > anyway. > > On what grounds? I can think of a couple of reasons: - Casting back and forth does not preserve information. (This may be true for some other type pairs as well, but in this case it's true in almost every instance.) - It's an arbitary definition that is not obviously supported by mathematical or similar principles. - It opens the door for other silly casts like empty string => false, non-empty string => true. - It's unnecessary because you can express the same thing using other expressions that clearly state what they do. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] int4 <-> bool casts
Peter Eisentraut wrote: - Casting back and forth does not preserve information. (This may be true for some other type pairs as well, but in this case it's true in almost every instance.) Right, there are many other explicit casts that lose information. In fact, I think that's somewhat the point of an explicit cast -- if a cast didn't lose information, it could be done implicitly. By explicitly casting something, the user is acknowledging that they accept the possibility of lost information. - It's an arbitary definition that is not obviously supported by mathematical or similar principles. It has a long standing precedent outside of mathematics, such as in C and derived programming languages. -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
