OK, I can see your point and I am sure you are right.
All this has to do with the question (discussed not long ago) how one
should know how the output from a statement should be handled by
an application receiving the data. In my case that application is Excel.
Take for example an integer. Excel need to know if this integer should
be formatted as a plain integer or as an Excel date. When the user moves
data to SQLite (from the sheet or from eg a text file) he/she will tell how
this data should be stored. In this case the data type will be INTEGER or
INT_DATE. This information will be stored in SQLite_master. The question
is now how to match up the columns of the output with these data types in
SQLite_master. I have a simple system for this with sqlite3_column_type
and sqlite3_column_decltype etc. but this is just not fool proof. It looks
I will need to think up some more elaborate system. One option is that the
just tells (along with the statement) what the output formatting should be,
but that would be cumbersome.


On Sun, Jan 7, 2018 at 9:10 PM, R Smith <ryansmit...@gmail.com> wrote:

> On 2018/01/07 10:11 PM, Bart Smissaert wrote:
>> Sure, in that case there can be no sensible column name.
>> In the great majority of cases though the select field will be of a single
>> table column, with or without
>> an expression. In those cases it will be helpful to get the non alias
>> column name.
> To repeat an answer by Richard given for a recent other question (if a
> little paraphrased):
> How much extra code, resources and memory are you willing to spend for ALL
> future queries so that you can know the sometimes available original column
> used in an alias?
> I would prefer that answer to be "Zero".
> Bart:
> "One would think that if sqlite3_column_name can get the alias name then
> somehow it must
> be possible to get the real column name."
> One would be wrong if one would think that. Inside the code/engine there
> are no column names, only pointers, (in fact I think the engine has to make
> special memory space for storing the output names - it is this memory that
> gets interrogated when you call sqlite3_column_name()),  the names only
> exist as a method for humans to state the intent of the question - it is
> forgotten at earliest convenience if not directly intended for output, and
> those that do get added to output has to be collected/deduced at a non-zero
> resource cost already. (At least this is my current understanding, I might
> have it wrong).
> Btw. - I am quite sure this holds for all DB engines, but if there is an
> engine out there that do let you trace back, I'd be interested to know.
> Also, the assumption about the "vast majority of cases" is simply wrong.
> The vast majority of returned column names in queries are not aliases,
> indeed aliases are mostly used when the column value is a result of a
> function or combination of columns (such as Simon's reply suggested) where
> you need a good resulting reference name in the output. Are you using
> aliases for columns where they are not needed?
> Further to this, there is nothing wrong with copying the name in the
> alias, such as: SELECT MAX(ColA) AS ColA FROM ....
> Lastly, even if we involve zero column joining or functions, plain
> aliasing is a problem by itself. Consider this next query, what do you feel
> is the true original name of the output column sq1?
> SELECT sq1 FROM (SELECT vc1 AS sq1 FROM v1);
> sq1
> -----
>   X
> HTH, and I hope this adequately illustrates why your request is not
> possible currently, not trivial to implement and also not widely requested.
> Cheers!
> Ryan
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
sqlite-users mailing list

Reply via email to