Thread: 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