Thread

Re: OOP real life example (was Re: Why is MySQL more

Curt Sampson <cjs@cynic.net> — 2002-08-13T05:33:46Z

On Mon, 12 Aug 2002, Don Baccus wrote:

> Give it up.  You're acting like a turkey.  If you aren't, skin yourself
> a new non-turkey skin.

Since he appears not to be able to avoid abusive ad hominem attacks,
I'm now sending mail with "dhogaza@pacifier.com" in the From: header
to /dev/null. If there's a technical point in one of his messages that
relates to the discussion that I need to answer, someone should please
mention it on the list or forward it to me.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

Re: OOP real life example (was Re: Why is MySQL more

Greg Copeland <greg@copelandconsulting.net> — 2002-08-13T05:40:14Z

On Tue, 2002-08-13 at 00:33, Curt Sampson wrote:
> On Mon, 12 Aug 2002, Don Baccus wrote:
> 
> > Give it up.  You're acting like a turkey.  If you aren't, skin yourself
> > a new non-turkey skin.
> 
> Since he appears not to be able to avoid abusive ad hominem attacks,
> I'm now sending mail with "dhogaza@pacifier.com" in the From: header
> to /dev/null. If there's a technical point in one of his messages that
> relates to the discussion that I need to answer, someone should please
> mention it on the list or forward it to me.
> 

Curt, I think his reply stems from his frustration of chosen content in
many emails that originate from you.  We all pretty well understand
postgres has a broken feature.  We all understand you see zero value in
it.  We're all actively attempting to determine ways to make it less
broken, if not altogether better.  The fact that it's broken and you
hardly go an email reminding everyone of this fact is certainly not
making friends.  In fact, one should hardly be surprised you're not
seeing more retorts as such.

For the sake of the project, I'd hope you could give the "broken" topic
a rest, move on, and allow a little time for the list to settle again. 
If such abuse continues, then IMHO, it would make sense to /dev/null
him.

Greg

Re: OOP real life example (was Re: Why is MySQL more

Lamar Owen <lamar.owen@wgcr.org> — 2002-08-13T14:00:13Z

On Tuesday 13 August 2002 01:40 am, Greg Copeland wrote:
> On Tue, 2002-08-13 at 00:33, Curt Sampson wrote:
> > On Mon, 12 Aug 2002, Don Baccus wrote:
> > > Give it up.  You're acting like a turkey.  If you aren't, skin yourself
> > > a new non-turkey skin.

> > Since he appears not to be able to avoid abusive ad hominem attacks,
> > I'm now sending mail with "dhogaza@pacifier.com" in the From: header
> > to /dev/null. If there's a technical point in one of his messages that
> > relates to the discussion that I need to answer, someone should please
> > mention it on the list or forward it to me.

> Curt, I think his reply stems from his frustration of chosen content in
> many emails that originate from you.  We all pretty well understand
> postgres has a broken feature.  We all understand you see zero value in

Knowing Don to some extent, I can say with some assurance that his 'attacks' 
are never unprovoked.  
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: OOP real life example (was Re: Why is MySQL more

Curt Sampson <cjs@cynic.net> — 2002-08-14T00:07:56Z

On Tue, 13 Aug 2002, Lamar Owen wrote:

> > Curt, I think his reply stems from his frustration of chosen content in
> > many emails that originate from you.  We all pretty well understand
> > postgres has a broken feature.  We all understand you see zero value in
>
> Knowing Don to some extent, I can say with some assurance that his 'attacks'
> are never unprovoked.

Sorry; I'm not aware of the circumstances under which one is supposed
to call someone a "dick-waver" and other such things on a technical
mailing list.  Perhaps you can explain to me when one should be
doing this, so I too can do it at the appropriate times.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

Re: OOP real life example (was Re: Why is MySQL more

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-14T00:47:35Z

It is hard to argue with this logic.

---------------------------------------------------------------------------

Curt Sampson wrote:
> On Tue, 13 Aug 2002, Lamar Owen wrote:
> 
> > > Curt, I think his reply stems from his frustration of chosen content in
> > > many emails that originate from you.  We all pretty well understand
> > > postgres has a broken feature.  We all understand you see zero value in
> >
> > Knowing Don to some extent, I can say with some assurance that his 'attacks'
> > are never unprovoked.
> 
> Sorry; I'm not aware of the circumstances under which one is supposed
> to call someone a "dick-waver" and other such things on a technical
> mailing list.  Perhaps you can explain to me when one should be
> doing this, so I too can do it at the appropriate times.
> 
> cjs
> -- 
> Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
>     Don't you know, in this new Dark Age, we're all light.  --XTC
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: OOP real life example (was Re: Why is MySQL more

Don Baccus <dhogaza@pacifier.com> — 2002-08-14T01:36:41Z

Bruce Momjian wrote:
> It is hard to argue with this logic.

If he were actually making a technical argument I might actually agree 
with you myself.

Thus far all he's done is argue from authority, and in tight circles to 
boot.

Which means the term is an accurate description of his behavior ...

Here's a lengthier and polite description - he's trying to impress us 
with his brilliance which several of us are just too dense to recognize 
on our own.

-- 
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org

Re: OOP real life example (was Re: Why is MySQL more

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-14T01:38:15Z

Yea, you have to question what value the discussion has, really.  We
have users of inheritance that like it.  If we can get a TODO item out
of the disucssion, great, but there doesn't seem to be any direction of
where the discussion is heading.

---------------------------------------------------------------------------

Don Baccus wrote:
> Bruce Momjian wrote:
> > It is hard to argue with this logic.
> 
> If he were actually making a technical argument I might actually agree 
> with you myself.
> 
> Thus far all he's done is argue from authority, and in tight circles to 
> boot.
> 
> Which means the term is an accurate description of his behavior ...
> 
> Here's a lengthier and polite description - he's trying to impress us 
> with his brilliance which several of us are just too dense to recognize 
> on our own.
> 
> -- 
> Don Baccus
> Portland, OR
> http://donb.photo.net, http://birdnotes.net, http://openacs.org
> 
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: Inheritance

Hannu Krosing <hannu@tm.ee> — 2002-08-14T02:47:06Z

On Wed, 2002-08-14 at 09:38, Christopher Kings-Lynne wrote:
> >     1. The current implementation is broken.
> >
> >     2. We have no proper description of how a "fixed" implementation
> >     should work.
> 
> Surely 99% of the implementation problems	could be solved with an index type
> that can span tables?

Or constraints that can contain a subqueries.

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

Re: OOP real life example (was Re: Why is MySQL more

Hannu Krosing <hannu@tm.ee> — 2002-08-14T03:15:34Z

On Wed, 2002-08-14 at 05:07, Curt Sampson wrote:
> On Tue, 13 Aug 2002, Lamar Owen wrote:
> 
> > > Curt, I think his reply stems from his frustration of chosen content in
> > > many emails that originate from you.  We all pretty well understand
> > > postgres has a broken feature.  We all understand you see zero value in
> >
> > Knowing Don to some extent, I can say with some assurance that his 'attacks'
> > are never unprovoked.
> 
> Sorry; I'm not aware of the circumstances under which one is supposed
> to call someone a "dick-waver" and other such things on a technical
> mailing list.

It was quite clear what he meant but perhaps there is a better technical
term for use in a technical list, some 5-7 letter all-capital acronym
perhaps ;)

But as anyone should give the benefit of doubt, I've been assuming that
you are just playing devil's advocate .

> Perhaps you can explain to me when one should be
> doing this, so I too can do it at the appropriate times.

I guess what he meant was that you were arguing for arguments sake (mine
is better than yours! Yes it is! Yes it is! ...) and not to get to some
solution, dismissing perfectly good arguments with a simple"not true"
statements and suggesting people to read heavy books with the claim that
the truth is somewhere in there ;) 

So it seems that the "technical" content of his claim was quite similar
to some of yours ;)

This has been quite bizarre thread, with about half of traffic being
quite reasonable constructive discussion while the other half seems
definitely describable by the the word that would get me in your
killfile ;)

I'll be off to my vacation for two weeks now, and I'll try to come up
with consistent writeup of what our OO features should be (both
inheritance and others).

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

Re: OOP real life example (was Re: Why is MySQL more

Hannu Krosing <hannu@tm.ee> — 2002-08-14T03:26:19Z

On Wed, 2002-08-14 at 09:49, Curt Sampson wrote:
> On Wed, 14 Aug 2002, Bruce Momjian wrote:
> 
> > OK, great summary.  Isn't the bottom-line issue the limitation of not
> > being able to create an index that spans tables?
> 
> That would be one way to fix one particular problem. I can think of
> another way to fix it right off-hand. (Put the parent's part of the data
> in the parent table, the child's part in the child table and join.) But
> we haven't completely worked out what effect this has on other parts of
> the system, or what effect we're even looking for.

It would be cleaner in some parts while making things messier in others.

This would make INSERTs and UPDATEs much more complicated, and also
there would be a lot of joins for deeper inheritance hierarchies.

> An an example, at this point some people (including me) feel that
> constraints (*all* constraints) placed on a supertable should always
> work. This means that one should not be able to insert into a subtable
> anything that would break a supertable constraint, and one should not be
> able to add a constraint to a supertable that's violated by a subtable.

Agreed. Most of this would be easy to implement for curent
implementation (but perhaps no more efficient than when done by manually
added rules/triggers) if constraints could contain subqueries.

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

Re: OOP real life example (was Re: Why is MySQL more

Curt Sampson <cjs@cynic.net> — 2002-08-14T04:29:03Z

On Tue, 13 Aug 2002, Bruce Momjian wrote:

> Yea, you have to question what value the discussion has, really.  We
> have users of inheritance that like it.  If we can get a TODO item out
> of the disucssion, great, but there doesn't seem to be any direction of
> where the discussion is heading.

Summary:

    1. The current implementation is broken.

    2. We have no proper description of how a "fixed" implementation
    should work.

    3. It's hard to fix the current implementation without such a
    description.

    4. Thus, we are in other messages here trying to work out the
    model and come up with such a description.

    5. The people working this out at the moment appear to be me,
    Greg Copeland and Hannu Krosing.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

Inheritance

Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2002-08-14T04:38:55Z

>     1. The current implementation is broken.
>
>     2. We have no proper description of how a "fixed" implementation
>     should work.

Surely 99% of the implementation problems	could be solved with an index type
that can span tables?

Chris

Re: OOP real life example (was Re: Why is MySQL more

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-14T04:42:09Z

Curt Sampson wrote:
> On Tue, 13 Aug 2002, Bruce Momjian wrote:
> 
> > Yea, you have to question what value the discussion has, really.  We
> > have users of inheritance that like it.  If we can get a TODO item out
> > of the disucssion, great, but there doesn't seem to be any direction of
> > where the discussion is heading.
> 
> Summary:
> 
>     1. The current implementation is broken.
> 
>     2. We have no proper description of how a "fixed" implementation
>     should work.
> 
>     3. It's hard to fix the current implementation without such a
>     description.
> 
>     4. Thus, we are in other messages here trying to work out the
>     model and come up with such a description.
> 
>     5. The people working this out at the moment appear to be me,
>     Greg Copeland and Hannu Krosing.

OK, great summary.  Isn't the bottom-line issue the limitation of not
being able to create an index that spans tables?  Is there any way to
implement that?  We have sequences that can span tables.  Can that help
us?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: Inheritance

Curt Sampson <cjs@cynic.net> — 2002-08-14T04:43:43Z

On Wed, 14 Aug 2002, Christopher Kings-Lynne wrote:

> Surely 99% of the implementation problems could be solved with an
> index type that can span tables?

Maybe.

But my problem is not so much that it's broken, as nobody can
explain exactly what "fixed" would be. I mean, completely fixed,
not just one obvious problem fixed.

Just my opinion of course, but I think it would be best to have a
detailed description of how everything in inheritance is supposed to
work, write a set of tests from that, and then fix the implementation to
conform to the tests.

And I think a detailed description comes most easily when you have
a logical model to work from.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

Re: Inheritance

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-14T04:44:39Z

Christopher Kings-Lynne wrote:
> >     1. The current implementation is broken.
> >
> >     2. We have no proper description of how a "fixed" implementation
> >     should work.
> 
> Surely 99% of the implementation problems	could be solved with an index type
> that can span tables?

Right.  Instead of talking in circles, let's figure out how to do it.
If the issue is only sequence numbers, can we force a column to _only_
get values from the sequence counter, thereby makeing the index span
unnecessary?  Can't we look up stuff in parent/child index to check for
collisions before we add a row?  Doesn't seem too hard to me.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: Inheritance

Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2002-08-14T04:47:17Z

> Right.  Instead of talking in circles, let's figure out how to do it.
> If the issue is only sequence numbers, can we force a column to _only_
> get values from the sequence counter, thereby makeing the index span
> unnecessary?  Can't we look up stuff in parent/child index to check for
> collisions before we add a row?  Doesn't seem too hard to me.

Is it theoretically possible to add support to btree for storing table along
with the indexed value?  This would obviously add overhead, so it would only
be done for spanning indexes.  The index would also take up more space on
disk I guess.

When a new inherited table is created, all parent indices would be dropped
and recreated as spanning indices and vice versa.

Chris

Re: OOP real life example (was Re: Why is MySQL more

Curt Sampson <cjs@cynic.net> — 2002-08-14T04:49:32Z

On Wed, 14 Aug 2002, Bruce Momjian wrote:

> OK, great summary.  Isn't the bottom-line issue the limitation of not
> being able to create an index that spans tables?

That would be one way to fix one particular problem. I can think of
another way to fix it right off-hand. (Put the parent's part of the data
in the parent table, the child's part in the child table and join.) But
we haven't completely worked out what effect this has on other parts of
the system, or what effect we're even looking for.

An an example, at this point some people (including me) feel that
constraints (*all* constraints) placed on a supertable should always
work. This means that one should not be able to insert into a subtable
anything that would break a supertable constraint, and one should not be
able to add a constraint to a supertable that's violated by a subtable.
If after more work on this everybody agrees that this is really the way
to go, then that will have implications on the solution we pick.

There's also the matter of digging up the SQL standards for table
inheritance and deciding how closely we want to follow that. (Though
I think that that's best left to after a fairly formal logical
analysis of what table inheritance should be.)

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

Re: OOP real life example (was Re: Why is MySQL more

Don Baccus <dhogaza@pacifier.com> — 2002-08-14T12:56:30Z

Hannu Krosing wrote:

> I guess what he meant was that you were arguing for arguments sake (mine
> is better than yours! Yes it is! Yes it is! ...)

That's the dictionary definition of the phrase.

> and not to get to some
> solution,

and that's the source of the frustration.  I only re-subscribed to the 
list because we at OpenACS had examined PG's OO extensions quite 
thoroughly before rejecting the current implementation as being not 
useful for our work, and I thought our reasoning might be of interest.

> dismissing perfectly good arguments with a simple"not true"
> statements and suggesting people to read heavy books with the claim that
> the truth is somewhere in there ;) 

and that's what's I mean when I say he's been arguing from authority.

-- 
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org

Re: Inheritance

Don Baccus <dhogaza@pacifier.com> — 2002-08-14T13:02:17Z

Bruce Momjian wrote:
> Christopher Kings-Lynne wrote:
> 
>>>    1. The current implementation is broken.
>>>
>>>    2. We have no proper description of how a "fixed" implementation
>>>    should work.
>>
>>Surely 99% of the implementation problems	could be solved with an index type
>>that can span tables?
> 
> 
> Right.  Instead of talking in circles, let's figure out how to do it.
> If the issue is only sequence numbers, can we force a column to _only_
> get values from the sequence counter,

Even if primary keys were forced to be generated from a sequence (a very 
artificial restriction), unique constraints are also implemented by 
index.  And people also join on columns other than their primary key so 
will want indexes on these columns to span tables, also.

-- 
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org

Re: OOP real life example (was Re: Why is MySQL more

ngpg@grymmjack.com — 2002-08-14T13:36:42Z

> Summary:
> 
>     1. The current implementation is broken.
> 
>     2. We have no proper description of how a "fixed" implementation
>     should work.
> 
>     3. It's hard to fix the current implementation without such a
>     description.
> 
>     4. Thus, we are in other messages here trying to work out the
>     model and come up with such a description.
> 
>     5. The people working this out at the moment appear to be me,
>     Greg Copeland and Hannu Krosing.
> 
> cjs

I've been following the thread on and off, but maybe we should come up with 
a list of specifically what is broken... I have used the oo feature in the 
past and the only thing I dont care for about it is the lack of 
documentation/examples/etc of how it really works and the fact that 
constraints/indicies/etc are not inherited by child tables.

Re: Inheritance

Tom Lane <tgl@sss.pgh.pa.us> — 2002-08-14T13:59:15Z

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Is it theoretically possible to add support to btree for storing table along
> with the indexed value?

That's what we need, all right.

> This would obviously add overhead, so it would only
> be done for spanning indexes.  The index would also take up more space on
> disk I guess.
> When a new inherited table is created, all parent indices would be dropped
> and recreated as spanning indices and vice versa.

Seems like the hard way.  Instead use a t_infomask bit in indextuples to
indicate that the index entry points to a table other than the one its
index is nominally associated with; if and only if this bit is set, the
table OID follows the indextuple header.  This way, you don't have to
reindex just to create a child table, and you also don't pay any extra
space cost for index entries that in fact point at the parent.

There are a veritable ton of other issues to be resolved --- like how do
we (efficiently) find all the indexes relevant to a given child table
--- but the physical storage doesn't seem too complicated.

			regards, tom lane

Re: OOP real life example (was Re: Why is MySQL more

Greg Copeland <greg@copelandconsulting.net> — 2002-08-14T14:25:02Z

On Tue, 2002-08-13 at 23:42, Bruce Momjian wrote:
> Curt Sampson wrote:
> > On Tue, 13 Aug 2002, Bruce Momjian wrote:
> > 
> > > Yea, you have to question what value the discussion has, really.  We
> > > have users of inheritance that like it.  If we can get a TODO item out
> > > of the disucssion, great, but there doesn't seem to be any direction of
> > > where the discussion is heading.
> > 
> > Summary:
> > 
> >     1. The current implementation is broken.
> > 
> >     2. We have no proper description of how a "fixed" implementation
> >     should work.
> > 
> >     3. It's hard to fix the current implementation without such a
> >     description.
> > 
> >     4. Thus, we are in other messages here trying to work out the
> >     model and come up with such a description.
> > 
> >     5. The people working this out at the moment appear to be me,
> >     Greg Copeland and Hannu Krosing.
> 
> OK, great summary.  Isn't the bottom-line issue the limitation of not
> being able to create an index that spans tables?  Is there any way to
> implement that?  We have sequences that can span tables.  Can that help
> us?
> 

Actually, I'm not sure that is the bottom line.  One of the reasons I
ask so many questions is because I'm trying to understand what the "is"
case is.  For me, that is important before I can understand, not only
what the "to-be" picture should be, but what needs to be done to get
there.

Because of that, I tend to agree with Curt.  We need to fill in 1, 2,
and 3.  As for item number 4, I was hoping that other references would
at least help us understand a "defacto" implementation.

Long story short, for me, it's easy to superficially agree that we need
indexes that span tables but I still have no idea if that really
constitutes "the bottom-line".

Regards,
	Greg Copeland

Re: Inheritance

Greg Copeland <greg@copelandconsulting.net> — 2002-08-14T14:35:10Z

On Wed, 2002-08-14 at 08:59, Tom Lane wrote:
> There are a veritable ton of other issues to be resolved --- like how do
> we (efficiently) find all the indexes relevant to a given child table
> --- but the physical storage doesn't seem too complicated.

Tom, seems we have yet another false start.  Thanks for offering your
comments on the topic at hand.  Since you seem to have a good grasp on
the the "is" case is, would you be willing to offer up some additional
details on what you feel the ("veritable ton of") outstanding issues
are?

Seems everyone clearly wants a cure and is itching to get there, yet I
don't fully understand the disease.  I suspect that there are others in
the same boat.  I feel that this is important for us all of understand. 
I think we need to understand what our "to-be" picture is as well as
what points need to be addressed before we can say we've arrived.

Willing to help spell this out?

Regards,
	Greg Copeland

Re: Inheritance

Greg Copeland <greg@copelandconsulting.net> — 2002-08-14T14:39:06Z

On Tue, 2002-08-13 at 23:43, Curt Sampson wrote:
> Just my opinion of course, but I think it would be best to have a
> detailed description of how everything in inheritance is supposed to
> work, write a set of tests from that, and then fix the implementation to
> conform to the tests.
> 
> And I think a detailed description comes most easily when you have
> a logical model to work from.

I completely agree.  This is why I want/wanted to pursue the theory and
existing implementations angle.

Seems like everyone trying to jump on "index spanning" is premature.

Doesn't Oracle have table inheritance?  Hmmm...I might have to go do
some reading to find out one way or anther...  ;)

Sign,
	Greg Copeland

Re: OOP real life example (was Re: Why is MySQL more

Tom Lane <tgl@sss.pgh.pa.us> — 2002-08-14T14:42:21Z

Hannu Krosing <hannu@tm.ee> writes:
> Agreed. Most of this would be easy to implement for curent
> implementation (but perhaps no more efficient than when done by manually
> added rules/triggers) if constraints could contain subqueries.

I don't understand what a constraint containing a subquery means.
Does it constrain the table(s) referenced by the subquery too?  If not,
what's the point --- adding, dropping or altering rows in the referenced
table might make the constraint condition false.  If it does constrain
the referenced tables, how the heck are you going to implement that in a
reasonable fashion?

			regards, tom lane

Re: Inheritance

Ross Reedstrom <reedstrm@rice.edu> — 2002-08-14T15:17:58Z

On Wed, Aug 14, 2002 at 09:39:06AM -0500, Greg Copeland wrote:
> On Tue, 2002-08-13 at 23:43, Curt Sampson wrote:
> > Just my opinion of course, but I think it would be best to have a
> > detailed description of how everything in inheritance is supposed to
> > work, write a set of tests from that, and then fix the implementation to
> > conform to the tests.
> > 
> > And I think a detailed description comes most easily when you have
> > a logical model to work from.
> 
> I completely agree.  This is why I want/wanted to pursue the theory and
> existing implementations angle.

In theory, it sounds like a good idea. In practice ... ;-)

> Seems like everyone trying to jump on "index spanning" is premature.

Seems like some people haven't looked at the history of the OO
implementation in PostgreSQL.

Actually, I think you'll find that once a PostgreSQL DBA gets to
the point of designing a sufficently complex schema that inheritance
might be useful, they quickly bump up against the lack of index and
constraint spanning (most notably, referential integrity), and stop
right there. This means that there is little community experience with
the existing implementation, beyond the OO die hards. ;-)

I'm not sure, but Bruce's suggestion of getting index spanning working
first might move the existing implementation over the hump from
'interesting toy' to 'less than perfect implementation'. Then, the
community can get some real world experience.

Bruce has archived some of the emails - check your local pgsql source tree,
under <$PGSQLHOME>/doc/TODO.detail/inheritance

There was also some theoretical OO discussion, back when the change for
default SELECT behavior on an inhertiance tree was made. (You used to
have to say: SELECT foo from parent* to get foo from the parent and all
children) Take a look at the archives and see if there's anything in that
discussion that interests you: providing summary posts of old discussions
is often a good way to restart and move an unresolved topic along.

Ross

Re: Inheritance

Joe Conway <mail@joeconway.com> — 2002-08-14T15:32:11Z

Ross J. Reedstrom wrote:
> Actually, I think you'll find that once a PostgreSQL DBA gets to
> the point of designing a sufficently complex schema that inheritance
> might be useful, they quickly bump up against the lack of index and
> constraint spanning (most notably, referential integrity), and stop
> right there. This means that there is little community experience with
> the existing implementation, beyond the OO die hards. ;-)

I'd have to agree wholeheartedly with this, because this was exactly my 
experience the one time I wanted to use inherited tables.

FWIW, one thought I've had before related to inheritance (but pretty 
much orthognal to this discussion) is this: if inheritance included 
shared indexes and constraints, we would be not too far from having 
Oracle style table partitioning.

Joe

Re: Inheritance

Greg Copeland <greg@copelandconsulting.net> — 2002-08-14T15:48:01Z

On Wed, 2002-08-14 at 10:17, Ross J. Reedstrom wrote:
> On Wed, Aug 14, 2002 at 09:39:06AM -0500, Greg Copeland wrote:
> > I completely agree.  This is why I want/wanted to pursue the theory and
> > existing implementations angle.
> 
> In theory, it sounds like a good idea. In practice ... ;-)
> 

LOL.  :)

> > Seems like everyone trying to jump on "index spanning" is premature.
> 
> Seems like some people haven't looked at the history of the OO
> implementation in PostgreSQL.

[waving hand...]

> 
> Bruce has archived some of the emails - check your local pgsql source tree,
> under <$PGSQLHOME>/doc/TODO.detail/inheritance
> 
> There was also some theoretical OO discussion, back when the change for
> default SELECT behavior on an inhertiance tree was made. (You used to
> have to say: SELECT foo from parent* to get foo from the parent and all
> children) Take a look at the archives and see if there's anything in that
> discussion that interests you: providing summary posts of old discussions
> is often a good way to restart and move an unresolved topic along.

Thanks!  I briefly read something about that in the archives.  Excellent
pointers.  I'll check that out.  If I have time, I'll try to summarize
and post.


Greg Copeland

Re: OOP real life example (was Re: Why is MySQL more

Lamar Owen <lamar.owen@wgcr.org> — 2002-08-14T15:55:55Z

On Tuesday 13 August 2002 08:07 pm, Curt Sampson wrote:
> On Tue, 13 Aug 2002, Lamar Owen wrote:
> > > Curt, I think his reply stems from his frustration of chosen content in
> > > many emails that originate from you.  We all pretty well understand
> > > postgres has a broken feature.  We all understand you see zero value in

> > Knowing Don to some extent, I can say with some assurance that his
> > 'attacks' are never unprovoked.

> Sorry; I'm not aware of the circumstances under which one is supposed
> to call someone a "dick-waver" and other such things on a technical
> mailing list.  Perhaps you can explain to me when one should be
> doing this, so I too can do it at the appropriate times.

I never said I agreed with his wording; in fact I don't agree with his 
wording.  But that's not the point.  The point is that the discussion was 
going absolutely nowhere, quickly.  Don's colorful metaphors (for lack of a 
better term) aren't ones I would use, by any means -- but they had the 
desired effect, didn't they?

The discussion has since progressed from 'the feature is broken because I say 
it is' to 'how can we fix the broken feature' -- which is where Don, Hannu, 
and Greg, unless I am mistaken, were all going towards.  If you, Curt, were 
just trying to play devil's advocate you went just a little too far, too 
vehemently, and were flamed in the old alt.flame tradition.  Had the words 
'Hitler' or 'Nazi' shown up we would have known it had gone the next step -- 
and I'm just relating Usenet tradition here -- I'm not a party to that 
tradition, but I certainly have seen enough flamewars to know what they 
disintegrate into.  I for one am glad you toned down the 'devil's advocate' 
point of view so that a useful discussion arises (which has indeed happened).

And I just stated my experience with Don -- no agreement (or judgment) was 
implied or stated.  I've just developed code beside him before.  I wish I had 
more time to develop code on OpenACS, in fact -- but that's even further 
off-topic.  Don Baccus is well-mannered and even tempered until provoked.  
When provoked; well, you see what happens.

Now, let's see the constructive discussion continue, without authoritarian 
posturing (for lack of a more technical term for Don's colorful metaphor).
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Re: Inheritance

Tom Lane <tgl@sss.pgh.pa.us> — 2002-08-14T16:05:37Z

Greg Copeland <greg@CopelandConsulting.Net> writes:
> On Tue, 2002-08-13 at 23:43, Curt Sampson wrote:
>> And I think a detailed description comes most easily when you have
>> a logical model to work from.

> I completely agree.  This is why I want/wanted to pursue the theory and
> existing implementations angle.

> Seems like everyone trying to jump on "index spanning" is premature.

I agree.  Table-spanning indexes would be a large, complex,
difficult-to-get-right feature.  Before diving into that we should get
some idea of just how we'd actually use them, and whether that's the
only big chunk of work standing between us and a more useful inheritance
feature.  I'm afraid we might do all that effort and then discover there
are other showstoppers.

			regards, tom lane

Re: Inheritance

Rod Taylor <rbt@zort.ca> — 2002-08-14T16:49:08Z

On Wed, 2002-08-14 at 11:17, Ross J. Reedstrom wrote:
> On Wed, Aug 14, 2002 at 09:39:06AM -0500, Greg Copeland wrote:
> > On Tue, 2002-08-13 at 23:43, Curt Sampson wrote:
> > > Just my opinion of course, but I think it would be best to have a
> > > detailed description of how everything in inheritance is supposed to
> > > work, write a set of tests from that, and then fix the implementation to
> > > conform to the tests.
> > > 
> > > And I think a detailed description comes most easily when you have
> > > a logical model to work from.
> > 
> > I completely agree.  This is why I want/wanted to pursue the theory and
> > existing implementations angle.
> 
> In theory, it sounds like a good idea. In practice ... ;-)
> 
> > Seems like everyone trying to jump on "index spanning" is premature.
> 
> Seems like some people haven't looked at the history of the OO
> implementation in PostgreSQL.
> 
> Actually, I think you'll find that once a PostgreSQL DBA gets to
> the point of designing a sufficently complex schema that inheritance
> might be useful, they quickly bump up against the lack of index and
> constraint spanning (most notably, referential integrity), and stop

Only took a few minutes to write a couple of triggers to manage most of
my needs.  Not very generic, but gives me cross table uniqueness ;)

Re: Inheritance

Curt Sampson <cjs@cynic.net> — 2002-08-15T00:05:51Z

On Wed, 14 Aug 2002, Tom Lane wrote:

> I agree.  Table-spanning indexes would be a large, complex,
> difficult-to-get-right feature.  Before diving into that we should get
> some idea of just how we'd actually use them, and whether that's the
> only big chunk of work standing between us and a more useful inheritance
> feature.  I'm afraid we might do all that effort and then discover there
> are other showstoppers.

That's my biggest fear as well. Here are a couple of possible
assertions we could make about supertables and subtables that have,
I think, some fairly far-reaching implications.

    1. All constraints one places on a supertable must "work." That is,
    they must apply on all subtables as well, and must always be true
    on the supertable. For example, if I apply the constraint, "this
    int field must be no smaller than 1 and no larger than 100," to the
    supertable, this must apply to all subtables, and you must not be
    able to remove the constraint from just a subtable."

    2. It must not be possible apply a constraint to a supertable that
    could be violated.

    3. All constraints that one can apply to a non-inherited table in
    postgresql must also be able to be applied to a supertable.

Depending on which of these you want to implement, and how you do
it, you may get yourself into a position where you can create a
table that that cannot have subtables, or cannot put certain constraints
on supertables....

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

Re: Inheritance

Tom Lane <tgl@sss.pgh.pa.us> — 2002-08-15T00:20:11Z

Curt Sampson <cjs@cynic.net> writes:
> That's my biggest fear as well. Here are a couple of possible
> assertions we could make about supertables and subtables that have,
> I think, some fairly far-reaching implications.

CHECK-style constraints don't seem like a huge issue to me.  We already
have recursive ALTER TABLE ADD CONSTRAINT, and IIRC we do actually
arrange for CHECK constraints on a parent to be inherited when a child
is created.  We could argue about whether, for example, non-recursive
ADD CONSTRAINT should be disallowed or not --- but that's not any kind
of implementation showstopper, just a definitional issue about
flexibility vs. safety.

It's nonlocal constraints that are the problem, and here foreign keys
and UNIQUE constraints are certainly the canonical examples.  Both of
these would be largely solved with table-spanning indexes I think.

What I'm not sure about is what other gotchas may be lurking...

			regards, tom lane

Re: Inheritance

Curt Sampson <cjs@cynic.net> — 2002-08-15T01:20:01Z

On Wed, 14 Aug 2002, Tom Lane wrote:

> It's nonlocal constraints that are the problem, and here foreign keys
> and UNIQUE constraints are certainly the canonical examples.  Both of
> these would be largely solved with table-spanning indexes I think.

Note that the other obvious way to solve this would be to store all of
the information inherited from the parent in the parent table, so that
you don't have to do anything special to make all of the constraints and
whatnot apply.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC