Subject | Re: Field names upper case - true of firebird 2.0 also? |
---|---|
Author | Adam |
Post date | 2005-05-09T23:30:01Z |
I think it is time we put this issue to bed :)
I think everyone agrees that my table that is called EMPLOYEECONTACT
would be easier to read if it was called EmployeeContact in the
administration tools.
Personally, I think it is silly to internally make Firebird do a case
insensitive comparison to the relation names. You are just making
extra work (admitedly only an XOR in most character sets), but if it
is not broken, why fix it?
As Helen pointed out in one of her posts, the query that a lot of
these dropdowns are filled by looks a bit like this.
select rdb$relation_name from rdb$relations
where rdb$relation_name not starting with 'RDB$'
What we probably would rather is some way of storing the friendly
name. A field like rdb$relation_name_minusH that could be filled with
the text as entered by the (create / alter) (table / view) DDL.
rdb$relation_name would still contain the upper case version. Then
the tools would just need to query that field instead.
Is it worth it, maybe, maybe not. I would personally be extremely
worried if any of my colleagues did not know the name of every table
they intend on querying backwards BEFORE they even thought about
writing a query. IMO, the sole reason for this "enhancement" would be
for improved code readability.
Adam
I think everyone agrees that my table that is called EMPLOYEECONTACT
would be easier to read if it was called EmployeeContact in the
administration tools.
Personally, I think it is silly to internally make Firebird do a case
insensitive comparison to the relation names. You are just making
extra work (admitedly only an XOR in most character sets), but if it
is not broken, why fix it?
As Helen pointed out in one of her posts, the query that a lot of
these dropdowns are filled by looks a bit like this.
select rdb$relation_name from rdb$relations
where rdb$relation_name not starting with 'RDB$'
What we probably would rather is some way of storing the friendly
name. A field like rdb$relation_name_minusH that could be filled with
the text as entered by the (create / alter) (table / view) DDL.
rdb$relation_name would still contain the upper case version. Then
the tools would just need to query that field instead.
Is it worth it, maybe, maybe not. I would personally be extremely
worried if any of my colleagues did not know the name of every table
they intend on querying backwards BEFORE they even thought about
writing a query. IMO, the sole reason for this "enhancement" would be
for improved code readability.
Adam