BTW: Not only Oracle replaces literal constants with parameters, it considers its type, it seems, for the ‘force_matching_signature’.
Of course, the question is: what were the requirements at the time when people designed calculation of that ‘force_matching_signature’. So, in a way it’s a deficiency in the requirements, not a bug in the code.

I was simply looking for ideas when I stumbled upon your page talking of somewhat related matter. I was hoping that you might have run into similar problem with non-matching semantically the same queries.
Oh well. I guess I better go and fill an enhancement request on Metalink then. Does not help but gives a false feeling of accomplishing something.

Thanks for your time!

a) Is it wrong because it’s not following specification – and the answer to that one is no; the definition is that it will match statements that differ only in their constants.

b) Is it wrong because it would be nice if it managed to see that these statements were the same. In that case we could say yes, it would be nice – but I think it might be quite difficult to achieve perfectly safely.

Here is some material for thought. The queries below have different FORCE_MATCHING_SIGNATURES.
Would not you agree that this is plainly wrong?

select 2+2 from dual
/
select 2+2 c1 from dual
/
select 2+2 from dual /**/
/
select 2+2 /**/ from dual
/
The real problem I am having is application layer generating non-deterministic aliases for columns (that’s Hybernate I’m talking about). As the result, there is no way to match the queries – for comparison of tests, for instance.

I wonder what your opinion is on this matter

Thanks,

Fudong