Re: [HACKERS] Inheritance

On 5/25/16 8:19 PM, Craig Ringer wrote: Postgres is well past the point where our relational features are the big selling point. It's now about scale, an incredibly robust storage engine, and all the extensiblity opportunities. We've moved from being an RDBMS to being a "Data

Re: [HACKERS] Inheritance

On 26 May 2016 at 01:56, Jim Nasby wrote: > On 5/24/16 8:52 PM, Craig Ringer wrote: > > Absolutely, and I use OO heavily. But a half-assed "object relational" > > feature in the database that only kind-of works isn't OO, and it's > > generally less useful than using

Re: [HACKERS] Inheritance

On 5/24/16 8:52 PM, Craig Ringer wrote: > Absolutely, and I use OO heavily. But a half-assed "object relational" > feature in the database that only kind-of works isn't OO, and it's > generally less useful than using existing relational-to-oo modelling > techniques like FK-related 1:1 child

Re: [HACKERS] Inheritance

On Tue, May 24, 2016 at 9:47 PM, Craig Ringer wrote: > On 24 May 2016 at 22:45, Konstantin Knizhnik > wrote: >> >> There is one aspect of inheritance support which was not mentioned: >> polymorphic queries. >> Actually polymorphism is the

Re: [HACKERS] Inheritance

On 24 May 2016 at 22:45, Konstantin Knizhnik wrote: > There is one aspect of inheritance support which was not mentioned: > polymorphic queries. > Actually polymorphism is the fundamental feature of OOP, without it there > is no behavioral inheritance and inheritance

Re: [HACKERS] Inheritance

On 24 May 2016 at 21:51, Jim Nasby wrote: > On 5/23/16 10:30 PM, Craig Ringer wrote: > >> I find it notable that no popular ORM has bothered adopting PostgreSQL's >> inheritance features, and instead just use big left joins or repeated >> SELECTs to implement

Re: [HACKERS] Inheritance

There is one aspect of inheritance support which was not mentioned: polymorphic queries. Actually polymorphism is the fundamental feature of OOP, without it there is no behavioral inheritance and inheritance can be considered just as "syntax sugar" for sharing some common subset of attributes

Re: [HACKERS] Inheritance

On 5/23/16 10:30 PM, Craig Ringer wrote: I find it notable that no popular ORM has bothered adopting PostgreSQL's inheritance features, and instead just use big left joins or repeated SELECTs to implement parent/child relationships, with foreign keys enforcing constraints. Since when do we

Re: [HACKERS] Inheritance

On 24 May 2016 at 00:05, Merlin Moncure wrote: > > This feature was very much a product of the time, at the height of the > "Object Relational" fad. The trend for postgres has been in the exact > opposite direction, towards the SQL standard. Further complicating > matters,

Re: [HACKERS] Inheritance

Tom Lane wrote: > My feeling about it is that we need to provide a partitioning feature > that doesn't rely on the current notion of inheritance at all. We've > heard from multiple users who want to use large numbers of partitions, > enough that simply having a separate relcache entry for each

Re: [HACKERS] Inheritance

Joe Conway writes: > But then again, maybe we need to start with a clear notion of what > problems people are trying to solve when they use partitions. At least > some of the historic reasons are no longer valid. That's true. Just because people want to have a gazillion

Re: [HACKERS] Inheritance

On 05/23/2016 03:05 PM, Tom Lane wrote: > Jim Nasby writes: >> I don't see why partitioning complicates fixing these issues. ISTM it's >> the exact same complaint for both inheritance and partitioning. > > My feeling about it is that we need to provide a partitioning

Re: [HACKERS] Inheritance

Jim Nasby writes: > On 5/23/16 11:05 AM, Merlin Moncure wrote: >> This feature was very much a product of the time, at the height of the >> "Object Relational" fad. The trend for postgres has been in the exact >> opposite direction, towards the SQL standard. Further

Re: [HACKERS] Inheritance

On 5/23/16 11:05 AM, Merlin Moncure wrote: Postgres doesn't work that way, and the documentation disclaims this: "Note: Although inheritance is frequently useful, it has not been integrated with unique constraints or foreign keys, which limits its usefulness. See Section 5.8 for more detail."

Re: [HACKERS] Inheritance

On Mon, May 23, 2016 at 10:21 AM, Jim Nasby wrote: > On 5/22/16 1:37 AM, Jan Johansson wrote: >> >> - Allow single (behavior) inheritance (model here is quite a few modern >> languages, such as C#, D, ...) >> - Allow multiple declarative inheritance (interface like,

Re: [HACKERS] Inheritance

On 5/22/16 1:37 AM, Jan Johansson wrote: - Allow single (behavior) inheritance (model here is quite a few modern languages, such as C#, D, ...) - Allow multiple declarative inheritance (interface like, the inheritance almost works like this today though) If, with these restrictions (or maybe

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

On Sun, Jun 21, 2015 at 5:45 AM, Dean Rasheed dean.a.rash...@gmail.com wrote: On 21 June 2015 at 05:27, Robert Haas robertmh...@gmail.com wrote: On Sat, Jun 20, 2015 at 6:48 PM, Tom Lane t...@sss.pgh.pa.us wrote: I propose instead the attached patch, which operates by identifying which of the

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

Dean Rasheed dean.a.rash...@gmail.com writes: However, there's an obvious improvement that can be made to Tom's patch -- having computed modifiableARIindexes, you may as well use it in the innermost loop to only apply ChangeVarNodes() to those AppendRelInfo's that can actually change, rather

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

On Fri, Jun 19, 2015 at 9:20 AM, Robert Haas robertmh...@gmail.com wrote: The extraordinarily planning time for query 4 is caused by a completely different problem: SearchCatCache eats up huge amounts of CPU; its callers are get_attavgwidth and get_typlen. It's not clear to me why doubling

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

Robert Haas robertmh...@gmail.com writes: Meanwhile, here is an updated patch. I don't care for that patch too much: it seems a bit brute-force, and I'm quite worried by the assumption that it's okay to destroy each child's append_rel_list after processing the child. That would fail if any of

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

On Sat, Jun 20, 2015 at 6:48 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Meanwhile, here is an updated patch. I don't care for that patch too much: it seems a bit brute-force, and I'm quite worried by the assumption that it's okay to destroy each child's

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

Petr Jelinek p...@2ndquadrant.com writes: On 2015-06-19 01:04, Petr Jelinek wrote: On 2015-06-19 00:38, Petr Jelinek wrote: On 2015-06-18 22:04, Tom Lane wrote: By the by, the tablesample additions to range_table_mutator are obviously broken. Apparently it's not a good idea to do this at

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

On Wed, Jun 17, 2015 at 9:56 AM, Robert Haas robertmh...@gmail.com wrote: On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro thomas.mu...@enterprisedb.com wrote: We saw a rather extreme performance problem in a cluster upgraded from 9.1 to 9.3. It uses a largish number of child tables (partitions)

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

On 18 June 2015 at 14:48, Robert Haas robertmh...@gmail.com wrote: On Wed, Jun 17, 2015 at 9:56 AM, Robert Haas robertmh...@gmail.com wrote: On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro thomas.mu...@enterprisedb.com wrote: We saw a rather extreme performance problem in a cluster upgraded from

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

Dean Rasheed dean.a.rash...@gmail.com writes: On 18 June 2015 at 14:48, Robert Haas robertmh...@gmail.com wrote: I feel I might be missing a trick here. It seems unlikely to me that we actually need the entire append_rel_list for every subquery; and we almost certainly don't need to modify

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

On Thu, Jun 18, 2015 at 3:14 PM, Tom Lane t...@sss.pgh.pa.us wrote: Dean Rasheed dean.a.rash...@gmail.com writes: On 18 June 2015 at 14:48, Robert Haas robertmh...@gmail.com wrote: I feel I might be missing a trick here. It seems unlikely to me that we actually need the entire append_rel_list

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

Robert Haas robertmh...@gmail.com writes: On Thu, Jun 18, 2015 at 3:14 PM, Tom Lane t...@sss.pgh.pa.us wrote: I'm a bit surprised that duplicating the append_rel_list is a noticeable performance problem. It ought to be far smaller than the Query tree that we've always duplicated in this loop

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

I wrote: Robert Haas robertmh...@gmail.com writes: Well, append_rel_list has an AppendRelInfo for every RTE and that contains a List (translated_vars) which in turn contains a Var node for every column. I'm not sure how that compares to the RTE itself. RTEs also have a per-column component,

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

On Thu, Jun 18, 2015 at 4:04 PM, Tom Lane t...@sss.pgh.pa.us wrote: ... although I see that range_table_mutator doesn't bother to copy/change the column alias substructure. (Wonder if that gives rise to any observable EXPLAIN bugs...) But it still seems like the append_rel_list shouldn't be

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

On 2015-06-18 22:04, Tom Lane wrote: By the by, the tablesample additions to range_table_mutator are obviously broken. Bah, typos. Attached patch corrects them. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services diff

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

On 2015-06-19 00:38, Petr Jelinek wrote: On 2015-06-18 22:04, Tom Lane wrote: By the by, the tablesample additions to range_table_mutator are obviously broken. Bah, typos. Attached patch corrects them. Actually it should probably look more like this, sorry. -- Petr Jelinek

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

On 2015-06-19 01:04, Petr Jelinek wrote: On 2015-06-19 00:38, Petr Jelinek wrote: On 2015-06-18 22:04, Tom Lane wrote: By the by, the tablesample additions to range_table_mutator are obviously broken. Bah, typos. Attached patch corrects them. Actually it should probably look more like

Re: [HACKERS] Inheritance planner CPU and memory usage change since 9.3.2

On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro thomas.mu...@enterprisedb.com wrote: We saw a rather extreme performance problem in a cluster upgraded from 9.1 to 9.3. It uses a largish number of child tables (partitions) and many columns. Planning a simple UPDATE via the base table started

Re: [HACKERS] Inheritance of foregn key constraints - dropping isinternal triggers by a

On Tuesday 01 of April 2014 11:06:00 you wrote: On Tue, Apr 1, 2014 at 9:13 AM, Andrzej Mazurkiewicz andr...@mazurkiewicz.org wrote: It seems that if the trigger is internal (tgisinternal = true) it is not visible to the DROP TRIGGER command. So it cannot be deleted using DROP TRIGGER

Re: [HACKERS] Inheritance of foregn key constraints.

Good Afternoon. Enclosed please find continuation of the discussion of an accidental or malicious breaking a server consistency. After reading please comment if there are more objections for changing the depedency type for trigger to constraint dependency from the DEPENDENCY_INTERNAL to

Re: [HACKERS] Inheritance of foregn key constraints.

On Tue, Apr 1, 2014 at 9:13 AM, Andrzej Mazurkiewicz andr...@mazurkiewicz.org wrote: It seems that if the trigger is internal (tgisinternal = true) it is not visible to the DROP TRIGGER command. So it cannot be deleted using DROP TRIGGER command, although the dependency type is

Re: [HACKERS] Inheritance of foregn key constraints.

Andrzej Mazurkiewicz andr...@mazurkiewicz.org writes: After reading please comment if there are more objections for changing the depedency type for trigger to constraint dependency from the DEPENDENCY_INTERNAL to DEPENDENCY_AUTO. I'm not sure which part of no you didn't understand, but we're

Re: [HACKERS] Inheritance of foregn key constraints.

On Tue, Apr 1, 2014 at 8:13 AM, Andrzej Mazurkiewicz andr...@mazurkiewicz.org wrote: That change is necessary to reduce scope of modifications necessary for an implementation of the inheritance of foregn key constraints, particularly for removing of objects. Nobody here is going to accept that

Re: [HACKERS] Inheritance of foregn key constraints.

Good Morning. 1. At the beginning some explanations. I am a lazy person that tries not to reinvent a wheel. So I try to use postgres way of automatic processing, i. e. automatic removing dependent objects (which I consider an elegant solution and I really like it). A a result, I have used the

Re: [HACKERS] Inheritance of foregn key constraints.

Andrzej Mazurkiewicz andr...@mazurkiewicz.org writes: So in other words, somebody could (accidentally or maliciously) break the constraint by dropping one of its implementation triggers. I doubt that's acceptable. The present postgres behavior ALLOWS accidental or malicious break the

Re: [HACKERS] Inheritance of foregn key constraints.

Andrzej Mazurkiewicz andr...@mazurkiewicz.org writes: My patch need one change that might be of significance. A type of the depencencies (pg_depend) among the FK constraint (pg_constraint) and the corresponding RI_ConstraintTrigger triggers has to be changed from DEPENDENCY_INTERNAL to

Re: [HACKERS] Inheritance and indexes

On Tue, Jan 14, 2014 at 12:07 PM, knizhnik knizh...@garret.ru wrote: But is it possible to use index for derived table at all? Yes, the planner will do an index scan when it makes sense. Why sequential search is used for derived table in the example below: insert into derived_table values

Re: [HACKERS] Inheritance, CREATE TABLE LIKE, and partitioned tables

On Mon, Jun 26, 2006 at 12:31:24PM -0400, Greg Stark wrote: Currently analyze.c and tablecmds.c both have some very similar code to handle copying columns from parent tables. As long as they were just copying columns and in the case of tablecmds.c copying check constraints that wasn't really

Re: [HACKERS] Inheritance, CREATE TABLE LIKE, and partitioned tables

elein [EMAIL PROTECTED] writes: People will turn around and immediately as for create table like without us making the assumptions it wanted all of the extras that come with inheritance. COPY is a copy of the table, not additional functionality. The added flexibility of adding only what is

Re: [HACKERS] Inheritance, CREATE TABLE LIKE, and partitioned tables

If you want to merge those functions, please do it as a separate patch now that the patch has been applied. Having too much unrelated stuff in a patch does confuse things. --- Greg Stark wrote: Currently analyze.c and

Re: [HACKERS] Inheritance, Primary Keys and Foreign Keys

A Saturday 13 May 2006 08:33, Thomas Hallgren va escriure: Albert Cervera Areny wrote: Of course, that's an option for my case. Just wanted to know if this solution could be useful for PostgreSQL in general. Mainly because I'll add some triggers to check what maybe PostgreSQL should do

Re: [HACKERS] Inheritance, Primary Keys and Foreign Keys

Albert Cervera Areny wrote: ...What do you mean with triggers that maintain cascade behavior? It ties on to how references are handled. Since they currently ignore the inheritance aspect, you need triggers that enforce 'on cascade delete/update'. They will become obsolete if that changes

Re: [HACKERS] Inheritance, Primary Keys and Foreign Keys

Ühel kenal päeval, N, 2006-05-11 kell 23:28, kirjutas Albert Cervera Areny: Of course, that's an option for my case. Just wanted to know if this solution could be useful for PostgreSQL in general. Mainly because I'll add some triggers to check what maybe PostgreSQL should do itself but it's

Re: [HACKERS] Inheritance, Primary Keys and Foreign Keys

Albert Cervera Areny wrote: Of course, that's an option for my case. Just wanted to know if this solution could be useful for PostgreSQL in general. Mainly because I'll add some triggers to check what maybe PostgreSQL should do itself but it's unimplemented. If that's not interesting or a

Re: [HACKERS] Inheritance, Primary Keys and Foreign Keys

Of course, that's an option for my case. Just wanted to know if this solution could be useful for PostgreSQL in general. Mainly because I'll add some triggers to check what maybe PostgreSQL should do itself but it's unimplemented. If that's not interesting or a proper solution for PostgreSQL

Re: [HACKERS] Inheritance, Primary Keys and Foreign Keys

Of course, that's an option for my case. Just wanted to know if this solution could be useful for PostgreSQL in general. Mainly because I'll add some triggers to check what maybe PostgreSQL should do itself but it's unimplemented. If that's not interesting or a proper solution for PostgreSQL I'll

Re: [HACKERS] Inheritance, Primary Keys and Foreign Keys

On Tue, 2006-05-09 at 01:20 +0200, Albert Cervera Areny wrote: In my particular case (don't know about the SQL standard or other cases), it'd be enough if when an inherited table is created: - A primary key in the inherited table is created with the same columns as the super

Re: [HACKERS] Inheritance

On Fri, 2002-09-06 at 19:00, elein wrote: There was a comment earlier that was not really addressed. What can you do with table inheritance that you can not do with a relational implementation? Or what would work *better* as inheritance? (you define better) There is nothing that you

Re: [HACKERS] Inheritance

On Fri, 2002-09-06 at 07:37, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: Suppose you have a table CITIZEN with table-level constraint IS_GOOD which is defined as kills_not_others(CITIZEN). and there is table CIVIL_SERVANT (..) UNDER CITIZEN. Now you have just one table

Re: [HACKERS] Inheritance

On 6 Sep 2002, Hannu Krosing wrote: In most object-oriented languages (Eiffel being a notable exception, IIRC), you can't specify constraints on objects. But in a relational database, you can specify constraints on tables, and it should *never* *ever* be possible to violate those

Re: [HACKERS] Inheritance

On Fri, 2002-09-06 at 09:53, Curt Sampson wrote: If the language specifies that contstraints on tables are not to be violated, then don't use those constraints when you don't want them. But what _should_ i use then if i want the same business rule on most top-level types, but a changed one

Re: [HACKERS] Inheritance

On Thu, 2002-09-05 at 15:51, Hannu Krosing wrote: On Fri, 2002-09-06 at 03:19, Greg Copeland wrote: What about the concept of columns being public or private? That is, certain columns may not be inherited by a child? Any thought to such a concept? Perhaps different types of table

Re: [HACKERS] Inheritance

On Fri, 2002-09-06 at 07:53, Hannu Krosing wrote: On Fri, 2002-09-06 at 09:53, Curt Sampson wrote: This looks like a classic case of incorrect modelling to me. Does the good itself change when it becomes a campaign_good? No. The price changes, but that's obviously not an integral part of

Re: [HACKERS] Inheritance

On Fri, 2002-09-06 at 07:37, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: Suppose you have a table CITIZEN with table-level constraint IS_GOOD which is defined as kills_not_others(CITIZEN). and there is table CIVIL_SERVANT (..) UNDER CITIZEN. Now you have just one table

Re: [HACKERS] Inheritance

On Fri, 2002-09-06 at 08:57, [EMAIL PROTECTED] wrote: On Fri, 2002-09-06 at 07:37, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: To elaborate on Gregs example if you have table GOODS and under it a table CAMPAIGN_GOODS then you may place a general overridable constraint

Re: [HACKERS] Inheritance

Oops! [EMAIL PROTECTED] (Greg Copeland) was seen spray-painting on a wall: --=-eu74lKXry3SVx8eZ/qBD Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2002-09-06 at 08:57, [EMAIL PROTECTED] wrote: On Fri, 2002-09-06 at 07:37, Curt Sampson wrote: On 5 Sep 2002,

Re: [HACKERS] Inheritance

There was a comment earlier that was not really addressed. What can you do with table inheritance that you can not do with a relational implementation? Or what would work *better* as inheritance? (you define better) This is a genuine question, not a snarky comment. I really want to know.

Re: [HACKERS] Inheritance

On Fri, 2002-09-06 at 11:05, [EMAIL PROTECTED] wrote: Oops! [EMAIL PROTECTED] (Greg Copeland) was seen spray-painting on a wall: That's a pretty forcible constraint. :-). =20 Is there something broken with your mailer? It's reformatting quotes rather horribly... Hmm...not that I know

Re: [HACKERS] Inheritance

On Thu, 2002-09-05 at 03:57, Curt Sampson wrote: On Tue, 3 Sep 2002, Bruce Momjian wrote: Yep, this is where we are stuck; having an index span multiple tables in some way. Or implementing it by keeping all data in the table in which it was declared. (I.e., supertable holds all rows;

Re: [HACKERS] Inheritance

On 5 Sep 2002, Hannu Krosing wrote: On Thu, 2002-09-05 at 03:57, Curt Sampson wrote: Or implementing it by keeping all data in the table in which it was declared. (I.e., supertable holds all rows; subtable holds only the primary key and those columns of the row that are not in the

Re: [HACKERS] Inheritance

On Thu, 2002-09-05 at 09:28, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: On Thu, 2002-09-05 at 03:57, Curt Sampson wrote: Or implementing it by keeping all data in the table in which it was declared. (I.e., supertable holds all rows; subtable holds only the primary key

Re: [HACKERS] Inheritance

On 5 Sep 2002, Hannu Krosing wrote: What I meant was that it is relatively more costly to update several physical tables than updating one . Oh, I see. Not that this is that big a deal, I think. Given that it doesn't work correctly at the moment, making it work fast is a definite second

Re: [HACKERS] Inheritance

I have a question about inheritance: You have 2 tables: Programmer and employee. Programmer inherits employee. You put in a generic employee record for someone, but then she becomes a programmer. What do you do? (I borrowed this example from a book by C.J. Date, who posed this question). Do

Re: [HACKERS] Inheritance

On Thu, 5 Sep 2002, Jeff Davis wrote: You have 2 tables: Programmer and employee. Programmer inherits employee. You put in a generic employee record for someone, but then she becomes a programmer. What do you do? (I borrowed this example from a book by C.J. Date, who posed this question). Do

Re: [HACKERS] Inheritance

On Thu, 2002-09-05 at 10:52, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: What I meant was that it is relatively more costly to update several physical tables than updating one . Oh, I see. Not that this is that big a deal, I think. Given that it doesn't work correctly at

Re: [HACKERS] Inheritance

On 5 Sep 2002, Hannu Krosing wrote: Oh, I see. Not that this is that big a deal, I think. Given that it doesn't work correctly at the moment, making it work fast is a definite second priority, I would think. But choosing an implementation that _can_be_ made to work fast is not. I would

Re: [HACKERS] Inheritance

This is not so wrong. If you think about it, you have the same problem in most object-oriented programming languages: a person object can't generally easily become a subclass of itself after being created. This is a case, I would say, where you simply don't want to use inheritance. A

Re: [HACKERS] Inheritance

On Thu, 2002-09-05 at 11:34, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: Oh, I see. Not that this is that big a deal, I think. Given that it doesn't work correctly at the moment, making it work fast is a definite second priority, I would think. But choosing an

Re: [HACKERS] Inheritance

On Thu, 2002-09-05 at 12:29, Jeff Davis wrote: This is not so wrong. If you think about it, you have the same problem in most object-oriented programming languages: a person object can't generally easily become a subclass of itself after being created. This is a case, I would say,

Re: [HACKERS] Inheritance

I really like Hannu's idea of storing an entire (single-inheritance) hierarchy in a single file. I guess the question we need to ask ourselves is if we're prepared to abandon support of multiple inheritance. Personally I am, but... regards, tom lane

Re: [HACKERS] Inheritance

On Thu, Sep 05, 2002 at 10:23:02AM -0400, Tom Lane wrote: I really like Hannu's idea of storing an entire (single-inheritance) hierarchy in a single file. Wouldn't this require solving the ALTER TABLE ADD COLUMN (to parent) column ordering problem? I guess the question we need to ask

Re: [HACKERS] Inheritance

On Thu, 2002-09-05 at 19:23, Tom Lane wrote: I really like Hannu's idea of storing an entire (single-inheritance) hierarchy in a single file. I guess the question we need to ask ourselves is if we're prepared to abandon support of multiple inheritance. Personally I am, but... So am I, but

Re: [HACKERS] Inheritance

On Thu, 5 Sep 2002, Jeff Davis wrote: But a person is-a employee (allow me to momentarily step aside from the rules of english grammer, if you would), and a person is-a programmer. That's why I didn't call my table job :) [1] Certainly it's not the case that a person is-a job, by virtue of

Re: [HACKERS] Inheritance

On Thu, 2002-09-05 at 08:15, Hannu Krosing wrote: On Thu, 2002-09-05 at 11:34, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: If that trigger is acting as an integrety constraint on the base table, you might destroy the table's integrity. What I try to say is that you should

Re: [HACKERS] Inheritance

On Fri, 2002-09-06 at 03:19, Greg Copeland wrote: On Thu, 2002-09-05 at 08:15, Hannu Krosing wrote: On Thu, 2002-09-05 at 11:34, Curt Sampson wrote: On 5 Sep 2002, Hannu Krosing wrote: If that trigger is acting as an integrety constraint on the base table, you might destroy the

Re: [HACKERS] Inheritance

On 5 Sep 2002, Hannu Krosing wrote: Suppose you have a table CITIZEN with table-level constraint IS_GOOD which is defined as kills_not_others(CITIZEN). and there is table CIVIL_SERVANT (..) UNDER CITIZEN. Now you have just one table MILITARY (...) UNDER CIVIL_SERVANT, where you have other

Re: [HACKERS] Inheritance

On 5 Sep 2002, Greg Copeland wrote: Sounds like a mechanism to make the distinction between virtual (child can override parent) and non-virtual (child is constrained by the parent) constraints are needed. Oh, I should mention that I have no problem with being able to declare a constraint

Re: [HACKERS] Inheritance

On Tue, 3 Sep 2002, Bruce Momjian wrote: Yep, this is where we are stuck; having an index span multiple tables in some way. Or implementing it by keeping all data in the table in which it was declared. (I.e., supertable holds all rows; subtable holds only the primary key and those columns of

Re: [HACKERS] Inheritance

The August draft of the SQL:200n standard (9075-2 Foundation) says in Section 4.17.2: Every table constraint specified for base table T is implicitly a constraint on every subtable of T, by virtue of the fact that every row in a subtable is considered to have a corresponding superrow in every one

Re: [HACKERS] Inheritance

Peter Gulutzan wrote: The August draft of the SQL:200n standard (9075-2 Foundation) says in Section 4.17.2: Every table constraint specified for base table T is implicitly a constraint on every subtable of T, by virtue of the fact that every row in a subtable is considered to have a

Re: [HACKERS] Inheritance

Seems with above you are not able to constrain what qualifies for a supertable row, you would only be able to specify constraints that apply to all it's subtables. Yes, that's the whole point. If I have a constraint on a table, I think it should *never* be possible for that constraint

Re: [HACKERS] Inheritance

On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote: Yes, that's the whole point. If I have a constraint on a table, I think it should *never* be possible for that constraint to be violated. If a subtable should not have constraint the supertable has, it shouldn't inherit from the

Re: [HACKERS] Inheritance

Yes, that's the whole point. If I have a constraint on a table, I think it should *never* be possible for that constraint to be violated. If a subtable should not have constraint the supertable has, it shouldn't inherit from the supertable. If you want that, you simply need to

Re: [HACKERS] Inheritance

On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote: So what you're saying is that constraints shouldn't be inherited? No. I even said that inheriting should be the default. Ah. So you think it should be possible not to inherit constraints. A local constraint should be made obvious from

Re: [HACKERS] Inheritance

On Mon, 2002-08-19 at 15:42, Curt Sampson wrote: A local constraint should be made obvious from looking at the schema, Ok, this now I could live with. Though I'm not sure that its theoretically very defensible, or worth the effort. Other languages that offer constraints, such as Eiffel

Re: [HACKERS] Inheritance

On Mon, 2002-08-19 at 09:42, Curt Sampson wrote: On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote: So what you're saying is that constraints shouldn't be inherited? No. I even said that inheriting should be the default. Ah. So you think it should be possible not to inherit

Re: [HACKERS] Inheritance

On Fri, 16 Aug 2002, Zeugswetter Andreas SB SD wrote: 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.

Re: [HACKERS] Inheritance

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

Re: [HACKERS] Inheritance

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?

Re: [HACKERS] Inheritance

Christopher Kings-Lynne [EMAIL PROTECTED] 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

Re: [HACKERS] Inheritance

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.

Re: [HACKERS] Inheritance

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

Re: [HACKERS] Inheritance

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

Re: [HACKERS] Inheritance

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

Re: [HACKERS] Inheritance

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.

  1   2   >