Subject | Re: [firebird-support] Upper case behaviour |
---|---|
Author | Lester Caine |
Post date | 2007-12-05T07:58:29Z |
Ann W. Harrison wrote:
UPPER CASE ( and was it 15 or 16 characters? ) I still prefer to hard code all
this in upper case. One can immediately see the SQL variables as against the
code variables. Every reserved word is upper case, and no object can map to
the reserved words AND any unquoted object name must only use the Latin
character set as defined in Unicode so while the 1332 page base SQL2003
standard COULD be bent to allow you to use LATIN upper and lower case letters
this should be kept where it is documented to be - within quotes.
Even when you try and nail every possible interpretation down people still try
and bend the rules, so another couple of 100 pages of standard get added :(
Yes Camel case and some of these other 'standards' are nice, but the SQL
standard is UPPER CASE and hopefully no one will start a discussion on
changing that for reserved words ;)
Having SAID all that, *I* get annoyed where tools ADD the double quotes.
Surely this is a matter of how you DISPLAY the returned information. If you
want Camel case then convert the displayed text? *OR* as SET said - use the
data supplied TO the tool to display the results. NOTHING has to change in the
engine :)
--
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php
> Eugen.Konkov@... wrote:As someone who started this lark back in the days when dBase only allowed
>> Hello
>> Can I disable server to uppercase object names?
>
> No. Firebird's handling of object names (aka identifiers) follows
> the standard and the behavior is used by tools that handle metadata.
>
> The ISO standard for the SQL language defined two types of identifiers,
> regular and delimited. Identifiers are the names of objects defined
> by users of SQL - tables, fields, indexes, constraints, functions,
> procedures, etc. Regular identifiers must begin with a letter - the
> standard provides a much more specific definition based on Unicode
> specifications - and can not contain spaces and most special characters.
> Delimited identifiers are enclosed in double quotes and can contain
> any character - though some must be escaped.
>
> Regular identifiers are case insensitive. Delimited identifiers are
> case sensitive. Case insensitivity is defined as allowing identifiers
> to match if their upper-case versions are equivalent. In several
> collations, more than one lower-case letter corresponds to a single
> upper-case letter, so the comparison "folds" to upper case.
>
> This means that some delimited identifiers - those in all upper-case
> that don't contain any characters not allowed in regular identifiers -
> are equivalent to non-delimited identifiers.
>
> For example "ABC" is equivalent to abc, Abc, AbC, etc. Many tools
> take advantage of that fact. When creating metadata objects out of
> stored names, they always quote the name stored in the schema.
UPPER CASE ( and was it 15 or 16 characters? ) I still prefer to hard code all
this in upper case. One can immediately see the SQL variables as against the
code variables. Every reserved word is upper case, and no object can map to
the reserved words AND any unquoted object name must only use the Latin
character set as defined in Unicode so while the 1332 page base SQL2003
standard COULD be bent to allow you to use LATIN upper and lower case letters
this should be kept where it is documented to be - within quotes.
Even when you try and nail every possible interpretation down people still try
and bend the rules, so another couple of 100 pages of standard get added :(
Yes Camel case and some of these other 'standards' are nice, but the SQL
standard is UPPER CASE and hopefully no one will start a discussion on
changing that for reserved words ;)
Having SAID all that, *I* get annoyed where tools ADD the double quotes.
Surely this is a matter of how you DISPLAY the returned information. If you
want Camel case then convert the displayed text? *OR* as SET said - use the
data supplied TO the tool to display the results. NOTHING has to change in the
engine :)
--
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php