Implicit casting and JOIN syntax constraints

>> HOWEVER.....look at this:
>> EXPLAIN ANALYZE select batchdetailid from batchdetail where batchdetailid = 27321::bigint;
>> Index Scan using batchdetail_pkey on batchdetail (cost=0.00..4.13 rows=1 width=8) (actual time=0.03..0.03 rows=1 loops=1)
>> Index Cond: (batchdetailid = 27321::bigint)
>> Total runtime: 0.07 msec

> Jeff Trout wrote:
> We had this happen to us - we had a serial8 column (int8) and our query
> was straight forward where id = 12345; which ran craptacularly. After
> much head banging and cursing I had tried where id = '12345' and it
> magically worked. I think the parser is interpreting a "number" to be an
> int4 instead of int8. (instead of quotes you can also cast via
> 12345::int8 like you did)

> Perhaps this should go on the TODO - when one side is an int8 and the
> other is a literal number assume the number to be int8 instead of int4?

It seems to me that this should absolutely go on the TODO list. Why does the planner require an explicit cast when the implicit cast is so obvious? Does Oracle do this? I can assure you that MSSQL does not.

If getting more people to migrate to PostgreSQL is a major goal these days, it's got to be relatively easy. I think that almost everyone coming from a MSSQL or Access background is going to have big problems with this. And the other issue of the JOIN syntax constraining the planner - you've got to be able to turn that off too. I've been writing SQL queries for 10 years in FoxPro, Access, SQL Server, MySQL, and Sybase. I have never come across this very confusing "feature" until now.

How do we go about voting an issue onto the TODO list? These two get my vote for sure!

Roman