> Does any SQL vendors behave like that ? I don't know of any vendor. > What do you mean by “sometimes" Quoted identifiers are sensitive and unquoted are not - that's what I meant that identifiers are "sometimes" case-sensitive.
> SQL must have a deterministic semantic I think. You can define a deterministic rule to decide which object to match, but it's just weird: if you compare identifiers to object names in a case-insensitive way, then having `MyTable` and `MYTABLE` should not be allowed. This weird situation can happen: - you create `MYTABLE` object - you have a query `SELECT * FROM MyTable` in your application - later you create `MyTable` object. It succeeds because it has a distinct name - the query now reads from a different table, even though the original object wasn't changed, just a new, distinct one was created. My point is that the behavior originally requested probably isn't a good idea. Regards, Viliam On Thu, 18 Jun 2020 at 10:41, Danny Chan <[email protected]> wrote: > > when the identifier was > > quoted and case-insensitive, if it wasn’t > > Does any SQL vendors behave like that ? What do you mean by “sometimes”, > SQL must have a deterministic semantic I think. > > Best, > Danny Chan > 在 2020年6月18日 +0800 PM4:23，[email protected]，写道： > > > > when the identifier was > > quoted and case-insensitive, if it wasn't > -- Viliam Durina Jet Developer hazelcast® <https://www.hazelcast.com> 2 W 5th Ave, Ste 300 | San Mateo, CA 94402 | USA +1 (650) 521-5453 | hazelcast.com <https://www.hazelcast.com> -- This message contains confidential information and is intended only for the individuals named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version. -Hazelcast
