"Ryan VanMiddlesworth" <ryanv+postgresql@xxxxxxxxx> writes: > I've got a very strange problem that I'm seeing in one of our PostgreSQL > databases (7.4.19). Specifically, I have a query that only uses the > functional index that it's supposed to use if I cast to text. Yeah, 7.4 is not very bright about realizing that these cases are equivalent and so it could match the query to the index either way. (8.0 and up get this right.) I think about all you can do in 7.4 is create the index to match the case you prefer to use, either with or without an explicit cast there. > ... But what is confusing me is the exact same setup works as expected > on our 7.4.7 database server (the problem server is 7.4.19). I suspect that the index was created with an explicit cast on one server, and not on the other. \d shows the two cases alike so it's hard to tell for sure, though if you want proof you could look into the expression strings in pg_index. > Also, why is PostgreSQL > requiring an explicit cast to 'text'? I thought varchar and text were > functionally identical data types. The cast is in fact a no-op (it's just a "RelabelType" node), but it's still got to be represented in the expression tree because some functions examine the declared type of their input expressions. \d (and also pg_dump) show implicit casts explicitly in certain contexts to be sure that the expression is interpreted the same way on reload, and not matched to some other function with the same name and different argument types. regards, tom lane
