Обсуждение: ONLY
Been trying to read the SQL3 draft. My best guess is that this
is the appropriate section...
Let T be the table identified by <ANSI> <table name> <ISO > <table or query name>
contained in a <table specification> TS.
...
c) If ONLY is specified, then TS identifies a table fo the
rows that do not have any corresponding row in any subtable of T.
I assume this a round-about way of saying that "ONLY" is used to exclude
subtables?
BTW, I think in SQL3 the oid column is supposed to be called "IDENTITY".
Maybe, but who can read this thing? (Can we find the people who wrote
this document and have them taken out and flogged?).
At 04:07 PM 2/7/00 +1100, Chris Bitmead wrote: >BTW, I think in SQL3 the oid column is supposed to be called "IDENTITY". >Maybe, but who can read this thing? (Can we find the people who wrote >this document and have them taken out and flogged?). It's not ALL that bad, my earlier comments were partly tongue in cheek. Mostly, it is obvious that you have to digest the whole thing in order to correctly understand bits and pieces. That was Jan's problem with "NO ACTION" and RI, leading him to believe that this meant he should leave dangling table references after deleting a referenced table. I knew that was wrong, and figured it had to do with the general definition of integrity constraints (i.e. there's a predicate function applied to the enttire database that must be true at strictly-defined times, and if not, errors spew forth and transactions roll backwards) but I'm damned if I could find it. Thus our difficulty in deciding what PG should do for such cases. But I know it is there... :) And Jan was as relieved as me to learn that it must be (because Date tells us so). Still, neither of us has seen it, we're just trusting Date and common sense (occam's razor, when in doubt, do the right thing). - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
> BTW, I think in SQL3 the oid column is supposed to be called "IDENTITY". > Maybe, but who can read this thing? (Can we find the people who wrote > this document and have them taken out and flogged?). Would that be enough? They'd sin on revenge, writing the next specs. Cut off hands and rip out tounge (or something that is really painful in in their terms - I'm unable to think about anything), so they are never of danger for the human community again. In fact, it's easier for me to interpret a sendmail.cf file than these specs. They'd been doing a better job by simply writing a gram.y with some appropriate comments - more readable and easier to adopt. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #
Don Baccus wrote: > It's not ALL that bad, my earlier comments were > partly tongue in cheek. <grumble> I think they're pretty bad. I did start reading from the beginning, even reading the definitions and there are many things that are not clear to me. If you think it's not too bad, do you care to comment on the "ONLY" situation?
At 07:42 PM 2/7/00 +1100, Chris wrote: >Don Baccus wrote: > >> It's not ALL that bad, my earlier comments were >> partly tongue in cheek. ><grumble> I think they're pretty bad. I did start reading from the >beginning, even reading the definitions and there are many things that >are not clear to me. >If you think it's not too bad, do you care to comment on the "ONLY" >situation? Well, OK, I was trying to be nice. Let me put it in a way that insults two standards committees at once: It's no harder to read than the C++ standard. How's that? :) Date's primer takes potshots at it in almost every section. One way in which the SQL standard IS worse than even your typically crummy language standard is that it apparently is not internally consistent. It contradicts itself in many areas, according to Date (who seems to take real pleasure in pointing out specifics). While all language standards have some bugs of this sort, the SQL standard seems to be full of them. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
On Mon, 7 Feb 2000, Don Baccus wrote: > While all language standards have some bugs of this sort, the SQL standard > seems to be full of them. *sigh* I hate it when people do this. YOU try writing a standard with that much information such that nobody will come back to you and say "you left such-and-such undefined". It's _very_ hard and requires a lot of definitions. I'll admit, however, that section summaries would be nice -- I had to wade through way too much stuff to find out what MATCH FULL meant exactly. Taral
At 12:54 PM 2/7/00 -0600, Taral wrote: >On Mon, 7 Feb 2000, Don Baccus wrote: > >> While all language standards have some bugs of this sort, the SQL standard >> seems to be full of them. >*sigh* I hate it when people do this. YOU try writing a standard with that >much information such that nobody will come back to you and say "you left >such-and-such undefined". I was at the very first organizational meeting for the creation of a standard for Pascal, and was very active at the beginning of that process (delegating it to someone else in my company when it got bogged down in paralytic discussions over whether to use a comma or semicolon to separate particular clauses, etc). Since the BSI nailed me to the cross and made me agree to be one of a half-dozen folks who met annually to accept or reject proposed additions to their test suite, I'm actually quite used to having folks tell me "you left such-and-such undefined". "you" in the collective sense of those who drafted the standard. Sometimes they were even right. I was also the BSI's designated technical consultant to the ISO committee convened by the BSI to standardize Modula-2. Though I got out of that thankless task after a year. I don't even know if they ever finished, because I dropped out of the computer industry shortly thereafter. So ... I am aware of how hard the problem is. And I've spent far too much of my life reading and reviewing proposed standards. The SQL seems to have more than its fair share of contradictions. Then again, SQL is far more complex than either of the languages I mentioned above. So's C++, and its standard is a morass that reflects the fact that the language itself is a morass. And Bjarne's just an...oh, let's not go there. I had friends (and one employee) on the ANSI committee, and dropped in on one meeting just to lend a sympathetic ear. I'm really glad I was smart enough to never come back, one meeting was enough! > It's _very_ hard and requires a lot of definitions. Yes, I know. That doesn't change the fact that the result in this case is extremely opaque! - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
Don Baccus wrote: > While all language standards have some bugs of this sort, the SQL standard > seems to be full of them. Does SQL3 seem to be going anywhere, or has the world lost interest in it?
> >*sigh* I hate it when people do this. YOU try writing a standard with that > >much information such that nobody will come back to you and say "you left > >such-and-such undefined". Like someone else said, if they at least supplied a compilable gram.y we'd at least have a definitive syntax, and could restrain ourselves to arguing about the meanings.