[EMAIL PROTECTED] wrote:
What does it do with queries that are pulling data from multiple tables? How
about computed column data?
Consider these queries:
SELECT a.c2, b.c3 FROM a, b WHERE a.c1 = b.c1;
SELECT c1 + c2 FROM a;
Derrell,
I don't see a problem with either of your problem queries.
For the first query it would return the rowid of the record in table a
for the first column, and the rowid of the record in table b for the
second column.
For the second query, it would return -1 as a sentinel value meaning
that the value is not located in a row of a table (i.e. you can't get
the rowid of a calculated value).
I do see a problem with queries that use a natural join or a join with a
using clause though. With the following tables and queries;
CREATE TABLE a (c1, c2);
CREATE TABLE b (c1, c3);
SELECT c1, c2, c3 FROM a NATURAL JOIN b;
SELECT c1, c2, c3 FROM a JOIN b USING(c1);
There is no way to know which table the c1 column value is associated
with (technically the selected columns in such joins don't belong to
either table according to the SQL standard) so no unique rowid can be
returned. I think it could simply be viewed as another form of
calculated column and return -1 for the rowid. That would make these
columns uneditable in the kind of applications that Ralf is concerned
with. This may seem a little unnatural at first, but you would not
usually be editing such columns in queries where they were used to join
multiple tables. If these columns are to be edited, it would have to be
through a query on one table or the other.
Dennis Cote
