> -----Original Message----- > From: Robert Simpson [mailto:[EMAIL PROTECTED] > Sent: Monday, February 28, 2005 12:55 PM > To: sqlite-users@sqlite.org > Subject: RE: [sqlite] ticket 1147 > > > -----Original Message----- > > From: Andrew Piskorski [mailto:[EMAIL PROTECTED] > > Sent: Monday, February 28, 2005 11:34 AM > > To: sqlite-users@sqlite.org > > Subject: Re: [sqlite] ticket 1147 > > > > On Mon, Feb 28, 2005 at 11:16:33AM -0700, Robert Simpson wrote: > > > > > Here are just a few things I can think of off the top of my > > head that I > > > cannot do right now for a resultset, but that I *can* do > > with additional > > > schema information: > > > > Do you mean that you would like additional schema > information added to > > the system tables, so that you could separately figure this sort of > > stuff out by querying them? > > No. There is sufficient information there already. > > > Or do you want this metadata returned with each and every resultset? > > Meaning, essentially, have the db (optionally) return a metadata > > resultset along with each normal data resultset. Is there some > > standard precisely specifying what this metadata resultset > should look > > like? > > Metadata should be on-demand, and not automatically returned. > As far as a standard is concerned, OLEDB and ODBC do it > differently and I'd have to look it up. At a minimum the > only columns required to implement this are: > > Column Name - The name of the column as specified in the > SELECT clause and what SQLite already generates Base Table - > The base table the column came from or NULL if the column was > computed Base Column - The base column of the table the > column came from or NULL if the column was computed Catalog - > The database the column came from or NULL if the column was computed. > > Given the above, where base column is not null, one can > retrieve the extended properties of those column(s) and build > the extended metadata for them. > > In a way, it's almost like a deviation from the EXPLAIN > keyword. Call it "METADATA" and it returns a row for each > column in the select clause containing the above information. > > Robert
Although I know nothing of the SQLite implementation details, it seems that this could be an extension along the lines of the existing sqlite3_column_decltype() function. sqlite3_column_decltype() returns the type, as a string, of a result column exactly as it was declared in the CREATE statement. Something like sqlite3_column_origname() could return the originating "<database>.<table>.<column>". Or it could be split up into 3 functions: sqlite3_column_origdatabase(), sqlite3_column_origtable(), and sqlite3_column_origname(). Tim
