Обсуждение: Re: OOP real life example (was Re: Why is MySQL more
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 alllight. --XTC
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
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
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 alllight. --XTC
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, Pennsylvania19073
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
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, Pennsylvania19073
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 alllight. --XTC
> 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
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, Pennsylvania19073
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 alllight. --XTC
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, Pennsylvania19073
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
> 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
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 alllight. --XTC
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
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
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
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
> 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.
"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
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
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
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
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
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
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
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
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
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
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 ;)
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 mustalways be true on the supertable. For example, if I apply the constraint, "this int field must be no smaller than1 and no larger than 100," to the supertable, this must apply to all subtables, and you must not be able to removethe 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 alllight. --XTC
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
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 alllight. --XTC