The Hermit Hacker wrote:
>
> On Fri, 19 May 2000, Hannu Krosing wrote:
>
> > The Hermit Hacker wrote:
> > >
> > > On Fri, 19 May 2000, Chris Bitmead wrote:
> > >
> > >
> > > > 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.
> > >
> > > Nope, my take on things is that your patch does things that would break
> > > existing functionality,
> >
> > IMHO it actually _fixes_ existing broken functionality .
>
> Oops, sorry, mis-spell ... would should be could ...
;)
> >
> > From where must he get that agreement ?
>
> >From more then two ppl? Actually, IMHO, it looks like alot of the problem
> is not that we should improve our OO, but how to go about it. It appears
> to me that the past thread that Chris started ended in a fashion that bred
> misunderstanding ... Chris thought it was resolved, others thought it got
> left hanging ...
>
> What *I'd* like to see is that past thread re-picked up again ... I'm
> going to take some time tonight to go through the archives and see if I
> can pull out "the start of the thread", will post it, and see if we can
> get some discussions going ...
>
> v7.0 hasn't been BRANCHED yet, so it can't go into the tree yet, but if we
> can take the next bit of time before it is BRANCHED to discuss it out and
> reach some sort of consensus here ...
Some sort of mission statement - what we want to accomplish and steps
to get there ?
> Chris, one quick question ... the last email I read from you stated a
> bunch of things that you wanted to accomplish, but your patch only
> addressed the first one. Can we focus on that and ignore the others? Do
> it through step'ng stones? Or does each step only make sense in view of
> the whole picture?
I guess the first step implemented in the patch is a useful fix in
its own right.
Alter table ONLY should be discouraged (maybe even forbidden in future)
Making Alter table to work efficiently on subtables would need some redesign
of tuple storage anyway, but this can probably postponed to when other things
are working. The same redesign would also give us efficient
ALTER TABLE DROP COLUMN.
Future things like having a unique index over all inherited tables require
more technical discussion as there are several vays to implement them, each
efficient for different use pattern.
btw. I'll be away from computer from now to monday, but I'm very much
interested in this topic and will surely followup then - it's a pain to do
all the OO in the frontend.
-------------
Hannu
