001package gudusoft.gsqlparser.sqlenv;
002
003/**
004 * How an identifier string reached the caller — the two forms are NOT
005 * interchangeable and selecting the wrong one silently produces wrong keys
006 * (plan §6, docs/designs/persistent-canonical-identity-implementation-plan.md).
007 *
008 * <p>The same character sequence means different things in the two forms:
009 * Oracle lexical {@code MixedCase} denotes the stored name {@code MIXEDCASE}
010 * (unquoted identifiers fold upper), while the catalog-stored string
011 * {@code MixedCase} IS the stored name, exactly as the data dictionary holds
012 * it — equal to the lexical spelling {@code "MixedCase"}, not to
013 * {@code MixedCase}.
014 *
015 * @since 4.1.5.15 (persistent canonical-identity slice U3)
016 */
017public enum IdentifierInputForm {
018
019    /**
020     * The string is SQL source text: quote recognition and strict decoding
021     * ({@link IdentifierCodec#decodeLexical}) apply, then the vendor's
022     * quote-state-specific fold. A recognized-but-malformed quoted spelling
023     * is REJECTED ({@link IdentifierCodec.MalformedIdentifierException}) by
024     * {@code persistentKeyV1} — the persistent API never guesses identity.
025     */
026    SQL_LEXICAL,
027
028    /**
029     * The string is a name read back from a database catalog / data
030     * dictionary (INFORMATION_SCHEMA, ALL_TABLES, a metadata export): it is
031     * already the stored payload. No quote recognition and no decoding are
032     * applied. The equivalence treatment is the one the vendor applies to
033     * stored names themselves: SENSITIVE domains keep the stored text;
034     * INSENSITIVE domains whose cell folds apply the cell's fold (idempotent
035     * on real catalog data — stored names ARE fold-images, so this keys them
036     * with the lexical spellings that produced them); never-folding
037     * INSENSITIVE cells use the case-fold collapse.
038     */
039    CATALOG_STORED
040}