Here’s how I would find out. Find the git commit where those properties were added. Look for tests added in the same commit. Do those tests cover the case you are interested in? Do those tests still work? How do they work? Step through them in the debugger if it’s not clear.
> On Dec 18, 2023, at 11:02 PM, Annepu, Sai Sriharsha > <saisriharsha.ann...@gs.com> wrote: > > Hi Julian > > Thanks for the response on this and suggesting use of QUOTED_CASING and > UNQUOTED_CASING properties. > > The values for these properties are either TO_LOWER, TO_UPPER or UNCHANGED. > But I don't not find an option which records if the identifier was > quoted/not. This information is being lost as part of the parsing is what I > feel. I would like to use this information to quote only those identifiers in > the final SQL post optimization. Please let me know if you have any questions > on this and if you want me to elaborate more. > > Thanks, > Sriharsha > > From: Annepu, Sai Sriharsha [Engineering] > Sent: Monday, December 18, 2023 7:11 PM > To: dev@calcite.apache.org > Cc: Ormerod, Andrew [Engineering] <andrew.orme...@ln.email.gs.com>; De Belen, > Pierre [Engineering] <pierre.debe...@ny.email.gs.com>; Harte, David > [Engineering] <david.ha...@ny.email.gs.com> > Subject: Case-sensitive parser configuration for quoted identifiers > > Hello Team, > > We are attempting to use Calcite as a dialect specific SQL string generator / > optimizer for SQL queries systematically generated by Legend data management > platform (https://github.com/finos/legend). > > In this context, I am trying to find if there exists a Calcite parser > configuration which allows case sensitive matching only if the identifier is > quoted, and also record that identifier as a quoted identifier to ensure it > remains the same in the final SQL generated by the dialect. quotedCasing and > unQuotedCasing configurations do help to some extent, but the identifier is > stored without quoting information. > > As an example, in the below SQL, I would like to do case in-sensitive > matching (from schema) for people table and name column but case sensitive > match for date column. Also, post parsing, validation and optimization, the > final SQL should have quotes only for date column - > > SELECT p.name AS name, p."date" AS dt FROM people AS p > > Does any such configuration exist? If it doesn't, can you please provide us > feedback on feasibility of the request and some pointers on where we can get > started if we want to contribute this feature. > > Thanks, > Sriharsha > > ________________________________ > > Your Personal Data: We may collect and process information about you that may > be subject to data protection laws. For more information about how we use and > disclose your personal data, how we protect your information, our legal basis > to use your information, your rights and who you can contact, please refer > to: www.gs.com/privacy-notices<http://www.gs.com/privacy-notices>
