Обсуждение: Re: Casting, again
> > btw, what were we hoping to accomplish with length(755)? Why isn't "3" > > a good answer?? > If you believe it should have an answer at all, then 3 is probably > the right answer. But it used to be rejected, and I tend to think > that that's the right behavior. I don't like the idea of silent > conversions from numeric-looking things into text. It might be > merely amusing in this case but in other cases it could be very > confusing if not outright wrong. Why was this change put in? Actually, I'm not sure a change *was* put in! I haven't yet looked, but it may be that this is a result of my adding a "number to text" conversion function. The type conversion code took that and ran! Remember that for v7.0, "length" for character strings should be "char_length". Maybe some of the trouble here is from leftover attempts to get strings and other "length" types to play together in an underspecified query. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > Actually, I'm not sure a change *was* put in! I haven't yet looked, > but it may be that this is a result of my adding a "number to text" > conversion function. The type conversion code took that and ran! Ah, I think you are right --- I was through the type-resolution code not too long ago, and I don't recall seeing any special cases for numeric->text either. It must be as you say, that the addition of this apparently harmless conversion function caused an unexpected change in the overall behavior. After reflecting on this example for a little bit, I like my proposal for explicit "promotability" links between types even better. The example illustrates that it's dangerous to have promotability decisions made on the basis of whether there happens to be a conversion function available or not. Offering a text(int4) function that users can call when they want to force a conversion is fine, but that should not automatically mean that the system can *silently* call it to cause an implicit conversion. Another example is that if we were to offer an int(bool) conversion function, as was suggested for the Nth time in a nearby thread, the current system would not allow us to control whether that conversion can happen implicitly --- it would, period. If implicit conversions can only follow specific "promotability" links then we don't have this risk. regards, tom lane
> If implicit conversions can only follow specific "promotability" links > then we don't have this risk. We've had some evolution in how we do type coersion and conversion, and istm that we are about ready to take the next step. Before, there were only a few folks thinking about it, and we implemented some steps to test out new ideas without making fundamental changes outside the parser. Now, we can make some more improvements based on experience with the current system. I like the idea of having some table-driven rules for implicit type coersion, since that technique can extend to user-defined types. The issues we have regarding string types and numeric types need to be thought through in the context of having *more* string types, which afaik is how we are going to integrate multibyte character sets into basic Postgres. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California