Sure, an API for returning result set info would be fine, and more convenient than these pragmas, which for one thing are stateful, and thus hell for wrapper writers, which need to assume that only the *wrapper* may set these pragmas. Also, in order to avoid API explosion, I feel that a single api function, named , say, sqlite3_column_origin, could return all relevant information, such as database, table, column names, and as a bonus, primary key and "required" (not NULL) flags. Still, and in order not to lose focus on ticket 1147, I reported a *bug* in the current implementation. The bug *is* there, and very easy to reproduce. I feel that this should either be fixed, or the pragmas removed altogether.
________________________________ From: D. Richard Hipp [mailto:[EMAIL PROTECTED] Sent: Mon 2/28/2005 9:24 PM To: sqlite-users@sqlite.org Subject: RE: [sqlite] ticket 1147 On Mon, 2005-02-28 at 11:54 -0700, Robert Simpson wrote: > 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. > OK. This is progress. Now I understand that people need the database, table, and column that resultset values originate from in order to automatically construct an appropriate UPDATE statement. That makes sense. Wouldn't it be better to provide this information with a new API rather than depend on a column naming convention? That would avoid ambiguity in cases where users create dodgy column names that contain characters like space and '.' If such a new API appears soon, would people (please!) stop using those short_column_names and long_column_names pragmas? -- D. Richard Hipp <[EMAIL PROTECTED]>
