Issue Details (XML | Word | Printable)

Key: CORE-5766
Type: New Feature New Feature
Status: Open Open
Priority: Minor Minor
Assignee: Unassigned
Reporter: fbbt
Votes: 0
Watchers: 5
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Allow to retrieve original field names (without uppercasing)

Created: 05/Mar/18 03:54 PM   Updated: 07/Mar/18 10:28 PM
Component/s: Engine
Affects Version/s: 4.0 Beta 1
Fix Version/s: None

Issue Links:
Duplicate
 

QA Status: No test


 Description  « Hide
Examples:

-- select FieldName from T
-- select FieldName as FieldNameAlias from T

need a way to get FieldName and FieldNameAlias at client not just in uppercase, but in original case too (as they written in sql)

-- create table TableName (FieldName integer)
need a way to get TableName and FieldName from system tables not just in uppercase, but in an original case too (as they written in statement)

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sean Leyne added a comment - 05/Mar/18 04:12 PM
The Firebird engine is following the SQL standard as it relates to the handling of column names in results, by default all column names are case insensitive, and are returned in upper case.

Case sensitive handling for column names is supported via the SQL-92 "Delimited Identifiers" functionality. This requires that column names be defined and always referenced using quotes/". I.e. CREATE TABLE T ("FieldName" as SomeType); and Select "FieldName" from T


fbbt added a comment - 05/Mar/18 08:02 PM
Sean,
I don't ask to broke standard.
I don't ask to change old behaviour.
I ask for additional info in system tables and client api.

Mark Rotteveel added a comment - 06/Mar/18 07:00 AM
The way SQL works, if you didn't quote the object names, then those names **are** uppercase, even if you entered them lowercase or mixed case in the query. If you want to get those names as entered, then you must quote them.

You really need to motivate why you want this (explain the use case).

fbbt added a comment - 06/Mar/18 08:08 AM
I want to have a way to extract original names. That's all.
This does not breaks anything.

Original names for tables and fields can be placed in system tables. They can be used by IDEs, report designers, query builders.

Mark Rotteveel added a comment - 06/Mar/18 08:33 AM
That doesn't explain why you need the case from the query, and it doesn't provide a real use case. For create table xyz (...), the table name is XYZ, and recreating it with create table XYZ (...) or using XYZ in a query builder works just as well. If you want case preserved, you need to use create table "xyz" (...), etc.

I'm looking for a rationale (a 'business case' if you will) why the Firebird project should invest time and energy to build something like this, when there are a range of other issues to tackle and new features to build. You need to "sell" this feature (convince 'us' that we should build this).

fbbt added a comment - 06/Mar/18 12:30 PM
This is question of readability and usability.
Now I forced to use double quotes in names.
Now all my queries uses tons of double quotes. Why? Because I want to use normal names in my development tools (IBExpert, Delphi, FastReport).

I don'tt want to use underscores for dividing letters. Especially in current restriction of length = 31 symbol.
For example: field name CasingSizeOnInwardOpenWhenLock is 30 symbols. Without quotes it will be unreadable CASINGSIZEONINWARDOPENWHENLOCK, with underscores it will be CASING_SIZE_ON_INWARD_OPEN_WHEN_LOCK (> 31 symols)

Just compare:
select CasingSizeOnInwardOpenWhenLock from SomeTable
select "CasingSizeOnInwardOpenWhenLock" from "SomeTable"
select CASINGSIZEONINWARDOPENWHENLOCK from SOMETABLE
select CASING_SIZE_ON_INWARD_OPEN_WHEN_LOCK from SOME_TABLE


- normal names: https://www.devart.com/dbforge/sql/studio/query-builder.html
- uppercased names: https://www.devart.com/dbforge/oracle/studio/oracle-query-builder.html


Adriano dos Santos Fernandes added a comment - 07/Mar/18 10:28 PM
The request is very obvious, so I don't see any need to sell it.

It's obviously as the stored procedures source code being stored as entered, instead of keywords being upper-cased or extra spaces removed.