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 Plat
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 existing relational-to-oo mode
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 tables
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 fundamental feature of OOP, without it there
>> is no beha
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 can be considered just as
> "
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 parent/child relationships, with fore
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
b
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 cons
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, inheritance has been
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 pa
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 partitions
doesn't necess
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 feature
> that doesn't rely
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 complicating
>> matters, inhe
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."
Pe
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, the
>> inheritance almost wor
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 o
Dean Rasheed 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 than having it trawl
>
On Sun, Jun 21, 2015 at 5:45 AM, Dean Rasheed wrote:
> On 21 June 2015 at 05:27, Robert Haas wrote:
>> On Sat, Jun 20, 2015 at 6:48 PM, Tom Lane wrote:
>>> I propose instead the attached patch, which operates by identifying which
>>> of the append_rel_list entries actually contain subquery refer
On 21 June 2015 at 05:27, Robert Haas wrote:
> On Sat, Jun 20, 2015 at 6:48 PM, Tom Lane wrote:
>> I propose instead the attached patch, which operates by identifying which
>> of the append_rel_list entries actually contain subquery references, and
>> copying only those; the other ones are just l
On Sat, Jun 20, 2015 at 6:48 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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
the Vars/subexpression
On Fri, Jun 19, 2015 at 9:20 AM, Robert Haas 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 the number of relati
Petr Jelinek 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 1AM afte
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 th
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
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 --gi
On Thu, Jun 18, 2015 at 4:04 PM, Tom Lane 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 all that much b
I wrote:
> Robert Haas 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, namely the li
Robert Haas writes:
> On Thu, Jun 18, 2015 at 3:14 PM, Tom Lane 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 --- in particular, it's really a
On Thu, Jun 18, 2015 at 3:14 PM, Tom Lane wrote:
> Dean Rasheed writes:
>> On 18 June 2015 at 14:48, Robert Haas 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
Dean Rasheed writes:
> On 18 June 2015 at 14:48, Robert Haas 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 every element of the
>> append_rel_list f
On 18 June 2015 at 14:48, Robert Haas wrote:
> On Wed, Jun 17, 2015 at 9:56 AM, Robert Haas wrote:
>> On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro
>> 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 (part
On Wed, Jun 17, 2015 at 9:56 AM, Robert Haas wrote:
> On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro
> 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 UPDA
On Wed, Jun 17, 2015 at 9:32 AM, Thomas Munro
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
> using a very large amount of
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
> >
On Tue, Apr 1, 2014 at 8:13 AM, Andrzej Mazurkiewicz
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 goal as a valid reaso
Andrzej Mazurkiewicz 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 not
doing that.
>
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 DEPENDENC
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 DEPEND
Andrzej Mazurkiewicz 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
> constraint by dropping
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 p
Andrzej Mazurkiewicz 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 DEPENDENCY_AUTO.
So
On Tue, Jan 14, 2014 at 12:07 PM, knizhnik 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 (2,2);
> create in
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
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 w
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
>
Ü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
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 (i.
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 d
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
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 proper
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
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 su
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 y
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 th
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. Th
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 S
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 const
> 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 ju
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 par
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 t
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
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
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
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
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 "
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
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 migh
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
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,
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 ours
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
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
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 choosi
>
> 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.
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
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 corre
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).
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 yo
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 pr
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 t
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
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 al
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 o
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 corre
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
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 inhe
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 Eiffe
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 f
> > > 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 si
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 th
> > 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 con
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 appl
> > 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
>
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
Curt Sampson <[EMAIL PROTECTED]> 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
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 mor
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 inheri
Greg Copeland <[EMAIL PROTECTED]> 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
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 ... ;-)
>
1 - 100 of 114 matches
Mail list logo