What is a type error?

[Marshall]

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