> > > We've talked about examples like this before. I'm inclined to think
> > > that when we are unable to resolve an operator involving unknown-type
> > > inputs, we should try again assuming that the unknowns are of type
> > > 'text'. Comments?
> > Yes please. SQL and the rest of the world assumes the 'xxx' is a character
> > constant, only PostgreSQL doesn't.
And only Postgres is trying to have a properly built extensible type
system with fewer legacy "SQL80" holdovers. So don't start throwing
things out without having a solid alternative that considers these
cases.
In the case of length():
pre-7.0 used length() to give a "length" of several data types,
including strings and geometric types. This led to more instances of
parser confusion when using untyped strings, since there were more
possible matches of types and the function.
For 7.0, I changed the implementation to decouple string types and
other types by natively supporting char_length() (and
character_length()), the SQL92-defined length function(s) for strings.
I left length() for the other types.
I believe that this is mentioned in the release notes.
btw, what were we hoping to accomplish with length(755)? Why isn't "3"
a good answer??
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
