Tom Lane wrote:
>
> Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> > 3) Returning of sub-class fields. Any ODBMS *must* do this by
> > definition. If it doesn't, it isn't an ODBMS.
>
> Chris, you have a bad habit of defining away the problem. Not
> everyone is convinced upon this point,
You claimed to be convinced in the previous discussions. Who exactly
wasn't?
> and your assertions that
> there was consensus don't help your cause.
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, but you seem to be as close to a leader
as I'll find. On the sub-class returning issue you declared that you
understood that it was "good for a certain class of problems" or some
such. My take on the previous discussions were that a great number of
objections were resolved. Am I supposed to just sit on my bum waiting
for people who havn't even used an ODBMS to argue for a few years? I'm
quite willing to talk this all through again but it needs to reach
closure at some point.
> Possibly more to the point: your patch doesn't implement the
> above behavior AFAICS.
I know, it only implements the first point. But this is useful in
itself.
> (Certainly libpq is unprepared to support
> multiple tuple types returned in one SELECT --- and there are no
> frontend changes in your patch.) So it might help if you'd clarify
> exactly what the proposed patch does and doesn't do.
This is the third time I've submitted the patch and you examined it in
detail last two times. This is just a post-7.0 merge and I was expecting
it put in CVS now that 7.0 is done.
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.
