Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> I must admit to frustration here. Will I be issued with a certificate or
> something when an arbitrator declares "consensus". I can't fathom how
> decisions are made around here,
If necessary, hard decisions are made by agreement of the core committee
--- but core prefers not to impose answers on the community. If
possible we wait until we think we see a consensus on the mailing list.
(I say "we" since I was recently appointed to core, but being the junior
member of core I'm hardly the man in charge ;-). Perhaps I should also
point out that in sitting here and debating the technical issues with
you, I'm not speaking for core; I'm just speaking as another member of
the community. My opinion doesn't count any more than yours does,
unless it comes to a point of having to be settled by a core vote ...
which we'd rather avoid.)
> On the sub-class returning issue you declared that you understood that
> it was "good for a certain class of problems" or some such.
So I did, and I think there wasn't too much debate about that once you'd
exhibited some sample problems. As I recall it, the remaining debate
was mostly about whether we wanted to change the system's default
behavior (ie the results of SQL92-compatible syntax) to cater to that
class of problems. There was also concern about whether we shouldn't
look first at SQL3 and try to follow its lead. If I recall correctly,
you are pursuing some other document than SQL3?
> To repeat - it implements DELETE and UPDATE on inheritance hierarchies
> to correct old bit-rot, and it implements ONLY as relates inheritance
> hierarchies to exclude sub-classes. Oh, and the emacs pgsql code style
> lisp implementation is done right in the FAQ.
Fixing DELETE* and UPDATE* is clearly not going to raise any hackles,
since that won't hurt any working applications. Swapping the behavior
of SELECT and SELECT* (which is what you really mean by "ONLY", no?)
*will* break some extant applications, so the threshold for deciding
that that's a good thing to do is a lot higher. That's the point at
which we start wanting to be convinced that there's a community
consensus in favor of the idea, and also that we're not choosing the
wrong standard to follow. If we do break existing apps, we want to
break them once, not several times until we get it right...
regards, tom lane
