> -----Original Message----- > From: Darren Duncan [mailto:[EMAIL PROTECTED] > Sent: Monday, February 28, 2005 10:29 PM > To: sqlite-users@sqlite.org > Subject: [sqlite] new API for query column sources (was Re: > ticket 1147) > > Here are some alternate API naming suggestions, that I have > thought through at length and believe will work. > > Since the proposed new functions are all related and talk > about the source table or view columns for the query, they > should all have the word 'source' in their names. Here are > my suggestions for new functions (and we keep the old ones as > they are): > > sqlite3_column_source() or sqlite3_column_source_column() > sqlite3_column_source_table() > sqlite3_column_source_database() > > All 3 of the above functions return null values for a > calculated field, and non-null values for a non-calculated > field. The first function gives the source table or view > field/column name, and is the same as many databases return > when you say "select *". The second function gives the name > of the table or view; since another name for a "view" is a > "viewed table" (see SQL:2003), that name isn't inappropriate > when the source is a view. And the third function is the > database containing the source table. If desired, pair each > one with a second version for UTF16. >
I think your proposed functions are fine. However, I don't know if returning the view name for a column from a view is useful. I think always returning the source table is the way to go, since one of the driving reasons for these functions is the ability to update the source table from the result set, and views are read-only. Tim
