OO Patch

Chris Bitmead writes:

That also goes for the various ALTER TABLE [ONLY]
syntax additions. If I add a row to A only then B is no longer a subtable
of A.

I agree that the alter table only is crazy, but the functionality was
there before and I didn't want to be the one to take it out. But if
someone does I can't imagine I'd object.

Okay, I think I see what you're getting at. The "ONLY" syntax on DELETE,
UPDATE, and ALTER TABLE would provide an entry point for the current,
broken behaviour, for those who need it (though it's not really backwards
compatibility per se). We might want to flag these with warnings "don't do
that" and reserve the option to remove them at a later date, to save
people from attempting stupid things.

I guess what I might have alluded to with "design document" is that you
would have explained that connection, because I did look at the old
thread(s) and didn't have any clue what was decided upon. What I was also
wondering about were these things such as the "virtual" IDENTITY field
that was proposed, the `SELECT **' syntax (bad idea, IMO), and the notion
that a query could return different types of rows when reading from an
inheritance structure (a worse idea, IMO). I didn't know whether the patch
touched that. (I think now that it doesn't.)

I'll tell you what, I have some time next week, and I'll read up on SQL3.
Perhaps I'll survive it. ;-)

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Peter Eisentraut <peter_e@gmx.net> writes:

I guess what I might have alluded to with "design document" is that you
would have explained that connection, because I did look at the old
thread(s) and didn't have any clue what was decided upon.

AFAIR, nothing was decided on ;-) ... the list has gone 'round on this
topic a few times without achieving anything you could call consensus.

I think Robert Easter might have his hands on the right idea: there
is more than one concept here, and more than one set of applications
to be addressed. We need to break things down into component concepts
rather than trying for a one-size-fits-all solution.

I'll tell you what, I have some time next week, and I'll read up on SQL3.
Perhaps I'll survive it. ;-)

Daniel enters the lions' den ... good luck ;-)

regards, tom lane

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

I guess what I might have alluded to with "design document" is that you
would have explained that connection, because I did look at the old
thread(s) and didn't have any clue what was decided upon.

AFAIR, nothing was decided on ;-) ... the list has gone 'round on this
topic a few times without achieving anything you could call consensus.

Oh dear. I thought we had progressed further than that. I hope we're not
back to square one here.

I think Robert Easter might have his hands on the right idea: there
is more than one concept here, and more than one set of applications
to be addressed. We need to break things down into component concepts
rather than trying for a one-size-fits-all solution.

I can't see that anything I've proposed could be construed as
one-size-fits-all.

1) DELETE and UPDATE on inheritance hierarchies. You actually suggested
it Tom, it used to work in postgres (if you look at the V7.0 doco very
carefully, it still says it works!! though it probably hasn't since the
V4.2 days). It's really a rather obvious inclusion.

2) Imaginary classoid field. This is a very stand-alone feature, that I
didn't hear any objections to.

3) Returning of sub-class fields. Any ODBMS *must* do this by
definition. If it doesn't, it isn't an ODBMS. The only question is what
syntax to activate it, and I'm not much fussed about that.

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, and your assertions that
there was consensus don't help your cause.

Possibly more to the point: your patch doesn't implement the
above behavior AFAICS. (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.

regards, tom lane

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.

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.

Or to put things another way, my goal is to implement the ODMG
(http://www.odmg.org/) interface on postgresql. Nobody has said
*anything* like that this is a bad goal to aim for, or that there is a
better way of doing it.

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, and your assertions that
there was consensus don't help your cause.

I am convinced ;).

There should be no consensus that "there should be no way to
retrieve sub-fields" ;)

I agree that the default may well be to retrieve only fuelds of
base class.

Possibly more to the point: your patch doesn't implement the
above behavior AFAICS. (Certainly libpq is unprepared to support
multiple tuple types returned in one SELECT

IIRC Bruce removed that feature in Pg95 days claiming that it would
not be needed. If backend starts to support it again it would be
relatively easy to put back in.

Good Morning.

From user (somebody like me) point of view it is important that

documentation reflects relaity. I mentioned about the following discrepancy
a couple of months ago. The remark was thorougly ignored.

It is great that it will be corrected in the best possible way, it means
reality will be upgraded to documentation|
Regards,
Andrzej Mazurkiewicz.

On Fri, 19 May 2000, Chris Bitmead wrote:

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.

We have a list archive ... just to try and help out here, you
might want to try posting URLs to show quotes ... to back things up ...

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, which won't be permitted without one helluva good
explanation ...

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.

That won't happen ... v7.1, if you can get agreement, but not in the
current CVS tree ...

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 .

which won't be permitted without one helluva good explanation ...

Yes, that was The Hermit Hacker I fearfully referred to as misusing even
the current "OO" functionality when I warned people not to promote using
any half-baked OO features developers have forgot into PostgreSQL when they
converted a cool ORDBMS into a generlly usable (non-O)RDBMS.

It may be time to fork the tree into OO and beancounting editions ?
Especially so if the main tree will migrate to BDB ;-p

OOPostgreSQL sounds quite nice ;)

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.

That won't happen ... v7.1, if you can get agreement, but not in the
current CVS tree ...

From where must he get that agreement ?

---------------
Hannu

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 ...

which won't be permitted without one helluva good explanation ...

Yes, that was The Hermit Hacker I fearfully referred to as misusing even
the current "OO" functionality when I warned people not to promote using
any half-baked OO features developers have forgot into PostgreSQL when they
converted a cool ORDBMS into a generlly usable (non-O)RDBMS.

It may be time to fork the tree into OO and beancounting editions ?
Especially so if the main tree will migrate to BDB ;-p

OOPostgreSQL sounds quite nice ;)

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.

That won't happen ... v7.1, if you can get agreement, but not in the
current CVS tree ...

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 ...

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?

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

On Sat, May 20, 2000 at 09:42:45AM +1000, Chris wrote:

The Hermit Hacker wrote:

We have a list archive ... just to try and help out here, you
might want to try posting URLs to show quotes ... to back things up ...

I don't have much success with the archive. (Search for "Proposed
Changes" - the name of the thread. It yields zero results). The links
to the result urls are coloured the same whether you have visited them
or not (not a bright idea), and in general I'm skeptical the searching
works properly. I certainly can't lay my hands on quite a few important
postings.

http://www.postgresql.org/mhonarc/pgsql-hackers/2000-02/msg00050.html

Seems to be the start of it. The web server had an unfortunate hard drive
crash, from what I understand, and they've been rebuilding the indices
for the search engine. (I found this by greping my local 'all postgresql
list I subscribe to' archive, to find the date, then going to that page
on postgresql.org. One problem is that the 'by month' links in the mailing
list archives only give you _part_ of the month: you have to hit the
'next page' link at the top)

We're post v7.0 now, so presumably we are in pre-7.1 land right? Surely
any minor patches now can be done in a branch? I can understand
reluctance to branch with heavy development in progress pre-7.0 but once
you've released it's time to move on.

Nope - the standard release process for postgresql is tag at release date,
branch after the inital flurry of bug reports/patches settles down. This
avoids a lot of double patching for the bugs that the beta testers don't
find, but the general user community does.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005

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

Hannu Krosing <hannu@tm.ee> writes:

Certainly libpq is unprepared to support
multiple tuple types returned in one SELECT

IIRC Bruce removed that feature in Pg95 days claiming that it would
not be needed. If backend starts to support it again it would be
relatively easy to put back in.

Would it? libpq's internals might not care much, but it seems to me
that a rather significant API change would be needed, thus risking
breaking client applications. I'd want to see how the libpq API
changes before deciding how easy or hard this is ...

regards, tom lane

So is the "community" the hacking community?

It's kinda fuzzy, but in practice I'd say the readers of pgsql-hackers
and maybe pgsql-general.

regards, tom lane

Hannu Krosing <hannu@tm.ee> writes:

Certainly libpq is unprepared to support
multiple tuple types returned in one SELECT

IIRC Bruce removed that feature in Pg95 days claiming that it would
not be needed. If backend starts to support it again it would be
relatively easy to put back in.

Would it? libpq's internals might not care much, but it seems to me
that a rather significant API change would be needed, thus risking
breaking client applications. I'd want to see how the libpq API
changes before deciding how easy or hard this is ...

Since this came up, I don't remember removing any of this. I may have
given the OK to do it, though.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

The current API would not change. New APIs would be added. One option is
just add PQnfieldsv(result, tuple_number) to find the number of fields
in a particular tuple.

But then we started discussing postgres' lack of streaming result sets
and how we might rectify that at the same time.

And then it was discussed that PQ will be thrown out in favour of Corba
anyway.

And then I couldn't figure out where the project is heading, so I didn't
know what to work on, so I didn't. I want to know up front if PQ is
disappearing in favour of Corba or not.

OK, there are no plans to change PQ anytime soon. What someone may do
is to implement a CORBA network service that interacts with PostgreSQL.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Chris <chris@bitmead.com> writes:

And then I couldn't figure out where the project is heading, so I didn't
know what to work on, so I didn't. I want to know up front if PQ is
disappearing in favour of Corba or not.

At this point, I'd say no one knows that (although if Alex's opinion
of Corba is correct, I'd bet we won't be going to Corba after all...)
You can wait and see, or you can make a guess and expend effort on the
basis of a guess.

My guess is that libpq won't be going away for a very long time. Even
if we adopted Corba or some other new protocol, we'd have a lot of
legacy clients that we'd want to support for the foreseeable future.
So it's probably worth improving libpq even if you think we will/should
adopt something else in the long run.

regards, tom lane