I looked up "idiosyncracy" in order to understand what is precisely
meant by that term and found that it seems to refer to "a way of
thinking (or a way of seeing things, or a way of looking at the world -
or certain aspects of that world-) that is "peculiar" and "eccentric"
and "pertains quite individually to the person holding those
isiosyncratic ideas/points of view/...



The problem(s) you refer to is, I presume, "how to do(/support) it".
It is -imo quite clearly- a problem for implementers (implementors ?)
(and possibly for the community of academic researchers researching
the issue). I fail to see how the set of implementers (UNION the set
of academic researchers researching the issue) can be described as
being "many, many others".



Apologies, but how do you match "widespread", with "idiosyncratic",
given the meaning of the latter term I found in not-really-suspect
sources ?



If you accept the idea that "view updating" is a problem for the
(DBMS) implementers, how is it possible to NOT think of view updating
in terms of target relvars ? In fact, target relvars are all there
really is to the problem. The user targets a non-physically-existing
relvar (a non-base relvar), the machinery has NOTHING BUT base relvars
to satisfy the users's request. The implementer has to see to it that
what he does to the base relvars he has to his avail, will correctly
reflect the user's request. That's why Date came up with the
Assignment Principle, which would prohibit, a.o. and e.g., any
arbitrary insert into A MINUS A.




But aren't INSERT/DELETE and ASSERT TRUE/ASSERT FALSE really just
"appearances in different form" of one and the very same thing ?

If so, how can you be thinking in terms of either, "rather than" in
terms of the other ?



I can't. The only way in which the "problem" of "finding a unique
transformation" REALLY goes away, is by declaring it not to be a
problem.

IMO, that causes problems of its own.

(Well, I should amend that here. The other way that the "problem"
goes away, is by solving it, of course, as is the case with any
problem. Such a solution now has become conceivable, methinks, but it
can be labeled "naive", and is therefore probably still infeasible in
all but the simplest of settings.)



PS

Do you plan to attend in Newcastle ?

On 18/03/2011 9:15 AM, Erwin wrote:
....
Yes, I meant it that way - most of what I've seen to do with rdbms
theory and implementation seems burdened with all kinds of unnecessary
baggage which I do find peculiar.

Just my personal exposure. Whenever and wherever I've posted to the
effect that I don't see any real problem, the responses were universal
that I was wrong, missing some contextual point or other. Maybe
'universal' only amounts to several dozen people given my limited
experience but it seems a fair sample of interested people to me.
Heh, apologies if my offhand sample would be laughed at in a
comp.statistics newsgroup.
I realize that the procedural/imperative implementation camp includes a
number of people (just to take your other point, note I didn't say
'many', even though I suspect it's a majority of that camp) who insist
on relvars and assignment (or tables and language operators that amount
to the same thing AFAICT). Given their chosen languages I don't fault
them, it's just that I don't think all possible languages need those
concepts, eg., a functional language might depend on side-effects for
recording relations. As long as such side-effects don't allow logical
inconsistencies it wouldn't bother me. I think Date's Assignment
Principle is quite apt for the languages he targets but also that it's
probably subsumed by an even more general principle or two, such as not
inferring what is not inferable. But such might be so general as to
seem not useful to most people.

I prefer not to have to worry whether they are the same thing or not if
that can be safely avoided. My limited intellect finds it easier to
dispense with them, at least when trying to discuss theoretical
problems. I think the logical aspect of problems (if there are any
logical problems) should be dealt with before language problems.

I've seen you and other smart people write more or less to that effect
more than once. But every time I've tried to imagine what the database
looks like that they suggest has views that are ambiguous where certain
assertions are concerned, I see no ambiguity, just arbitrary biases. I
don't fault them for that, especially since my clumsy expression of
counter-examples is usually so lengthy that I find it hard to read what
I've myself written. Probably what I write is just as hard for them to
read as what Date and McGoveran have written is hard for me to read
(ie., almost impossible). I think Date and McGoveran are on the right
track at least at the point where they start out, but I can't tell if
they go off-track at some later point. Eg., I don't know why Date
suggests 'deleting from both sides' is 'appropriate' as often as he
suggests it is (I quote 'appropriate' because I'm not sure he used
exactly that word, in any case I don't think appropriateness comes into
it at all - either what I call an assertion and what some call an update
is consistent and non-ambiguous or not). Lots of times it seems to me
perfectly logical and not ambiguous to 'delete' from only one 'side'.
When it comes to what I believe McGoveran means by 'logical
independence' I'm a little more confident that he's on the right track
because I think it must be accepted that at any given time for some
particular purpose, every relation recorded by a dbms should have
exactly one set of logically equivalent predicates (otherwise
contradictions are possible). But I still can't be certain because I
suspect I don't appreciate all the intracacies in what he's written (or
what he presumably had written for him, I can't follow his 2007 patent
at all).

From that point of view, my attitude is probably naive but I would say
that is only because I don't know how to optimize for general cases. I
don't know how to prove that no practical optimization is possible so I
continue to think that I'm not (yet) naive about it! Ie., I don't yet
agree with that point of view. I think one could write an engine that
naively implemented the equivalent of join deletes and union inserts
without inconsistencies and it would be naive only in the sense that it
had very ponderous aka slow behaviour.

I worked there once, liked the Geordies very much and I thought the
night life was much livelier than London's, certainly more concentrated.
I suppose when the ttm experts meet it could be said that the db
talent in Newcastle will also be more concentrated than in many, many
other places! Much as I'd like to see it again, not having what most
people would call income, that seems unlikely.

On 18 mrt, 22:44, paul c <anonym... (AT) not-for-mail (DOT) invalid> wrote:

I suspect your "side-effects" are what Date calls "cheating" when it
comes to functional languages and how they do I/O.

At any rate, every single bone in my programmer's body tells me side-
effects are bad news. They are the pest AND the cholera. They are
variables existing (AND being updated !!!!) without having been
declared. Therefore, they are about not knowing the full results of
the execution of your program. And "not knowing the full and complete
result" is nothing more than, in a mathematical sense, not being truly
functional to begin with !!! You can call me biased if you want to.



But how would you prove absence of such inconsistencies ? If you
consider that the inconsistencies might appear only in the existing-
but-undeclared-variables that get updated "only as a side-effect" ?



One argument that is VERY strong, imo, is that if JOIN is commutative
(which it is), then A JOIN B is the very same thing as B JOIN A (the
_expressions_ are not identical, but the _value_ they _evaluate to_
are indeed guaranteed to be identical, and it is of course only that
_value_ we are ever interested in), and it would therefore be
extremely desirable for a view updating mechanism to treat a delete
from A JOIN B in guaranteeably the same fashion as a delete from B
JOIN A.

At least in the case where the system is not considering the effect
that any of the three possible solutions might have regarding
constraint violations, the only option that guarantees this behaviour
is the symmetric one.

But I'm sure you're aware of that argument already.



Based on what ?

Awareness of certain constraints that exist in the database you happen
to be looking at ?

(Note that RI constraints are usually taken as a very strong
suggesting factor in deciding how to interpret a delete-through-join
request. "Delete the 'one' side only if the tuple(s) deleted on the
'many' side is(are) the very last one(s)." is a very common example.
But can you prove that you can deduce the existence of a 1-n RI
constraint from any set of arbitrarily formulated constraint
expressions (as opposed to the traditional 'explicit' FK
declarations) ?



It is precisely that kind of naive that I was referring to. And
remembering what you once wrote about someone hooking a RACF call into
an SMF call (or was it the other way round ?), I'm surprised you seem
to consider the building of "naive" engines a worthwhile option.



Seems like lack of income is a common characteristic among DB talents.

On 18/03/2011 2:44 PM, paul c wrote:
For example, when I see (not very often, I'll admit, hope I've got the
syntax more or less right) an SQL statement such as "INSERT INTO R
VALUES ( A '1', B '2');, I remember this paragraph from McGoveran:


3. A DBMS that supports the relational model cannot be "magic." It
cannot compensate for ambiguity, intuit withheld information or
assumptions, or correct expressions that violate the designer's or
user's intent. If the designer fails to capture information in database
design, if information is hidden from the user, or if the user
incompetently fails to express their intent [Ed. Note: Or if the data
language is not sufficiently expressive], it will certainly produce
seemingly anomalous or "surprising" results when faced with these problems.


At the time I first saw it and still now, I thought the note from the
editor, who I assume was Fabien Pascal, about 'sufficiently expressive'
language was the statement in that paragraph that was most pertinent to
implementation.


My reason is the assumption that at any all times, all the relations
recorded by an rdbms must have predicates and implications of those
predicates that aren't contradictory. When I fooled around with this
stuff for a living, a guy I worked for used to dispense with customer
complaints about crashed or hung db engines with "well, would you rather
have a dbms that starts up and gives wrong answers?".


I mention this because personally I agree with the TTM definition of
'Insert B to A' as producing a relation that is the result of A <OR> B.
The reason for that is that the A-algebra seems much more formal, ie.
precise, to me than the verbose SQL definitions I can barely remember.


However, if the "VALUES ( A '1', B '2')" clause of the INSERT statement
stands for a relation, in other words 'B' above, I would say there is no
way B could possibly have the same predicate as A, unless A and B have
the same tuples. Since most of the time any useful INSERT statement is
not likely to satisfy this requirement, I would think a language
designer must recognize that A and B must have different predicates.


Personally, if I were designing a language, I think I would have to
state that B's predicate is indeterminate. It is only partly
determinate in the sense that the predicate can't be the same as A's
predicate. Therefore any desire to make it determinate must be
suppressed. My preference would be for the language to include the
assumption that B has no more meaning than that the VALUES clause
represents an assertion of the truth of a relation that contains only
the described tuple.


Given that preference, I think join deletes and union inserts become
mechanical problems. For me, in the end it amounts simply to a user
stating that the tuples of the literal B relation are (all) true and
that B's predicate is immaterial. With those two assertions, the
A-algebra is sufficient to describe what results a language should
produce without ambiguity.


The only reason I'm a little hesitant about the above is that some of
the deep thinkers go into a lot more detail, for example McGoveran talks
about relative complement and logical independence and Date talks about
symmetry and multiple assignment, et cetera. There's lots more that I
won't belabour, anyway I still can't see what symmetry has to do with
all of this, makes me wonder if I'm missing something deep (always
possible I admit!) that has nothing to do with language design.

On 18 mrt, 22:44, paul c <anonym... (AT) not-for-mail (DOT) invalid> wrote:

There might be a difference between what _YOU_ see when you look at
that database, and what the _DBMS_ sees when it "looks" at that
database.

_YOU_ are likely to look at that database with at least a background
awareness of what the _EXTERNAL_ predicates of the relvars are, plus
probably also with some awareness of what the "external predicates" of
the constraints on that database are. The _DBMS_ cannot do such a
thing. All the DBMS can do is to observe that "there are n (say, 3)
base relvars involved in this view, and there are m (say, 17) database
constraints involved with any of those n relvars, and the nature of
those database constraints can be really just anything". I have come
to be more and more convinced of the notion that getting a DBMS to
provide sensible support for view updating will require that DBMS to
"understand" constraints in exactly the same way as a human
"understands" them. And that's a tall order.

And if you could explain to me _what it is that you see_ (I mean the
"external predicate things" that you see), when you look at a
database, in such a way that you can define it (what you see) in
_formal, mathematical, algebraic, calculus_ terms, then I would start
implementing and become a wealthy man in no time at all (after my
implementation work is done, of course).

On 18/03/2011 4:36 PM, Erwin wrote:
I think you're no more biased than Date is when he advocates multiple
assignment. I can see that you need some language feature like that if
your chosen environment includes the ability to make relation values
persistent on the fly.


But the same effects that MA allows could theoretically be achieved by
referring to before and after values of some updated relvar R, not
through a relvar name but through two different named (immutable)
values, say R and R2. In other words, within some 'context', there is
only one value of R and one of R2. Not sure, but I'm guessing that R and
R2 would be what Date calls pseudo-variables, I haven't paid much
attention to what he's written about pseudo-variables. The 'context'
would be one of multiple possible situations.


In conventional languages the above might seem absurdly ponderous, eg.,
people might conclude that every program text can be executed only once.
But I'd say it depends on context. For example, I don't see why a
transaction couldn't be defined in terms that Jim Gray never suggested
(AFAIK). The transaction might depend on a starting value of R which
remains constant until the transaction has taken effect along with
values R2 which might be derived from R and R3 which might be derived
from R2 but which are both constant in the context of the transaction.
The context of the transaction exists only when the transaction is not
in effect. When all the assertion(s) of the transaction are in effect,
the 'side-effect' is that R2 and R3 are not referenceable but R has the
value that R3 had when the transaction was in effect.


I admit that one could say this is the same kind of effect that multiple
assignment has, just with slightly different clothing and maybe Date is
justified to call it 'cheating'. It's just personal with me, I'd rather
separate the concept from the immediate language which I think is a
neater way to get along and also I've long had a wish to write programs
the same way I was taught to write arithmetic algebra expressions as a
child and read them back so simply or test them with a truth table.
Perhaps that's an infantile wish that has only to do with my own
inability to be confident about keeping track of variables and statement
order. (Or maybe I'm just in my second childhood - if so, bring on the
third one!) Anyway, I do think that in the big scheme of things,
simpler and more predictable programs are much more important than most
db issues and the way to those involves minimizing the concepts that one
must be aware when coding.

On 18/03/2011 5:00 PM, Erwin wrote:

I think that's a good description of the opposite of what I suggest!
What I think the hard part is, as far as implementation is concerned, is
ignoring what I might happen to know about the 'external' predicate and
devise an engine that applies user assertions only to what is recorded
but at the same time, all that is recorded! If a language supported a
user asking which UNIONS are both empty and non-empty, the answer should
be none. If a language were not to support that query that would be an
example of a language that makes answering what I think is an important
question what you call a 'tall order'!

On 19 mrt, 01:30, paul c <anonym... (AT) not-for-mail (DOT) invalid> wrote:

Paul,

D(&D)'s reasons for advocating multiple assignment are amply
documented, and they have _nothing_ to do with "persistence", on the
fly or not.

The thing is (, they say, ) let's assume that "temprorary
inconsistencies" (database states that are in violation of some
constraint) are allowed to be "seen" by the program that created
them. That is, let's assume that a scenario is possible in which a
program issues a DML statement DML1 that gives rise to an inconsistent
database state, then regains control, does whatever it sees fit to do,
then issues a DML statement DML2 that dispenses with the
inconsistency.

How can you guarantee that "whatever that program saw fit to do",
would not ultimately produce information that is (in whatever indirect
way) dependent on the inconsistency created, and how can you guarantee
that such information, "derived from an inconsistency", does and will
not propagate to other programs via mechanisms outside the control of
the DBMS (such as queues, pipes, sequential files, LU62
connections, ...) ? Such that the inconsistency will ultimately be
visible to the entire world nonetheless ?

On 27/03/2011 1:32 PM, Erwin wrote:
Sorry, I should have said assignment, not multiple assignment. But I'll
admit I do have multiple assignment on the brain or what's left of mine,
mostly because of the sequencing requirement. Even when I've used
merely procedural languages (ie., without multiple-assignment), I've
always found putting statements in order to be the second-hardest and
sometimes slowest part of it all (deciding what to do is the hardest
part). What I like about multiple assignment is the idea of
'simulataneous' statements and I wonder why not have programs where all
statements are simultaneous and statement order doesn't matter.
Personally I think every dimension that can be removed from a
programming language is to the good. I don't think I'd mind leaving it
up to an environment to determine how a program's actions are to be
recorded even if CJ Date might call that 'cheating'.

On 28 mrt, 23:49, paul c <anonym... (AT) not-for-mail (DOT) invalid> wrote:

Procedural-or-not is completely orthogonal to supporting-MA-or-not.

Tutorial D is _entirely_ procedural, yet it fully supports MA.



Because in real-life(TM) there are situations where order-of-
assignment does matter. And therefore in our programs too, which are
ultimately about nothing else than "maintaining a (data) state which
can be regarded as a "model" for real-life", there are indeed
situations in which order-of-assignment does matter.



I think what CJD calls 'cheating' in the context of the discussion
subject of "functional languages", is the fact that those languages
_CLAIM_ to "involve no variables and no assignments at all", while if
you go look "under the covers", you inevitably find out that that
claim is a lie.

The "functional" quality of a "functional" program is that it "does
nothing else but generate a result". Note that I used the word
"generate" and _NOT_ the word "record" !!! A functional program can
"generate" the number three as a result, and that's it. You can look
at it, and note that the result is the number three, but _AS SOON AS
YOU DO ANYTHING TO ACTUALLY RECORD_ that result (such as assigning it
to some portion of the value of a DBVAR), you are outside the realm of
"true" functional programming !!!