Joachim Durchholz wrote: > Marshall schrieb: > > > But what you descrbe is certainly *not* possible in the > > relational algebra; alas that SQL doesn't hew closer > > to it. Would you agree? > > Yup, SQL (particularly its update semantics) aren't relational semantics. > Still, it's SQL we've been talking about. > > > Would you also agree that > > if a language *did* adhere to relation semantics, > > then relation elements would *not* have identity? > > (Under such a language, one could not have two > > equal records, for example.) > > Any identity that one could define within relational semantics would be > just equality, so no, it wouldn't be very helpful (unless as part of a > greater framework). > However, that's not really a surprise. Aliasing becomes relevant (even > observable) only when there's updates, and relational algebra doesn't > have updates.
Good point. Perhaps I should have said "relational algebra + variables with assignment." It is interesting to consider assignment vs. the more restricted update operators: insert, update, delete. I think I see what you mean about the restricted update operators working on identity. > >>> Okay. At this point, though, the term aliasing has become extremely > >>> general. I believe "i+1+1" is an alias for "i+2" under this definition. > >> No, "i+1+1" isn't an alias in itself. It's an expression - to be an > >> alias, it would have to be a reference to something. > >> > >> However, a[i+1+1] is an alias to a[i+2]. Not that this is particularly > >> important - 1+1 is replacable by 2 in every context, so this is > >> essentially the same as saying "a[i+2] is an alias of a[i+2]", which is > >> vacuously true. > > > > To me, the SQL with the where clause is like i+2, not like a[2]. > > I'd say WHERE is like [i+2]: neither is valid on its own, it's the > "selector" part of a reference into a table. Is it possible you're being distracted by the syntax? WHERE is a binary operation taking a relation and a filter function. I don't think of filters as being like array indexing; do they appear analogous to you? (Always a difficult question because often times A and B share some qualities and not others, and what does one call that?) > > However the situation in SQL strikes me as being different. > > If one is speaking of base tables, and one has two queries, > > one has everything one needs to know simply looking at > > the queries. If views are involved, one must further examine > > the definition of the view. > > Sure. Usually, SQL itself is enough abstract that no additional > abstraction happens; so even if you have aliasing, you usually know > about it. > I.e. when compared to what you were saying about Java: "It is possible > to have multiple references to a single Java mutable object and > not know it.", the "and not know it" part is usually missing. Yes! > The picture changes as soon as the SQL statements get hidden behind > layers of abstraction, say result sets and prepared query handles. > > ... Um... let me also restate the preconditions for aliasing become a > problem. You need three elements for that: > 1) Identities that can be stored in multiple places. > 2) Updates. > 3) Abstraction (of updatable entities). > > Without identities, there cannot be aliasing. > Without updates, the operation that makes aliasing problematic is excluded. > Without abstraction, you may have aliasing but can clearly identify it, > and don't have a problem. Aha! That description works very well for me. > I admit that identity cannot be reliably established in SQL. The > identity of a record isn't available (unless via OID extensions). > However, it is there and it can have effect. Yes, I think I see what you mean now. This is in part a consequence of the restricted update operators. Thanks, Marshall -- http://mail.python.org/mailman/listinfo/python-list
