> > On Mon, 2005-02-28 at 08:48 -0700, Robert Simpson wrote: > > > 5. What we do with the schema information or how well we > > compute it > > > is irrelevant. > > > > > > > No. It is exceedingly relevant if you want any cooperation > > from me in addressing the issue. > > > > There seem to be a lot of people who are emphatic about > > knowing which column in which table a value in the result set > > originated from. This makes no sense to me. Why do they > > care? What do these people do with result set values that > > originate from expressions or which are constants? What > > about the result set of compound selects or of natural joins > > where the origin column is ambiguous? If knowing the > > original column is so important, what do people do with those > > cases? Disallow them? What do other database engines > > (PostgreSQL, Oracle, MySQL) do in the way of revealing the > > originating column for result set values? Do they have some > > mysterious API that I have never seen? > > > > And why do people care? Can nobody give me a use case where > > it is important to know what the originating column for a > > result set value is? > > > > One example, ADO.NET (Robert S., correct me if I'm wrong here): > > Given a specific SELECT statement, ADO.NET has the capability to > automatically build the corresponding INSERT, UPDATE, and DELETE > statements, so the user can insert/update/delete values/rows in the > resultset and have those modifications sent back to the database. > But > in order to facilitate this, it must have a direct mapping between > resultset columns and the originating columns in the database. > > Tim McDaniel > (I wrote the original ADO.NET SQLite wrapper on sourceforge)
Interesting! How do they handle calculated columns and constraints and such? Does it just fail? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
