Subject: Tutorial

From: David Fetter <[email-masked]>
Date: Thu, 22 Jul 2004 15:21:04 -0700

Kind people,

I am writing a document patch for the tutorials section, and would
like to change the section on inheritance to reflect the fact that it
is not currently being developed, and has known serious bugs in
implementation.

I'm thinking that I should either change that section to a warning
about why this is an unsupported feature or remove it entirely, and
add some other tutorials, details TBD.  Some candidates for these
would include:

* JOINs
* set-returning functions
* ARRAYs
* version-dependant (I presume) hacks like ORDER BY ... LIMIT 1 vs MIN/MAX
* the perennial Stuff Dave Has Not Though Of.

What do you all think?

Cheers,
D
-- 
David Fetter [email-masked] http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!

---

From: "Scott Marlowe" <[email-masked]>
Date: Thu, 22 Jul 2004 17:12:27 -0600

> is not currently being developed, and has known serious bugs in

I'd call them deficiencies.  If inheritance allowed one to specify a pk
across inherited tables, but occasionally forgot to enforce it or
something like that, that would be a bug.

But I totally agree with adding that there are key features of an
inheritance system that are not implemented, are not being worked on,
and here's what they are... kind of approach.

> * the perennial Stuff Dave Has Not Though Of.

Sounds good.  I've got some time off, so I'd be happy to write some of
it too.  Not a fan of arrays in pgsql so I'm not very familiar with
using them.  The version dependent hacks / kludges should probably be in
some generic section on performance tuning queries or something like
it.  It may be well to have cross links from one set to the other where
these are concerned, for instance the fact that in earlier versions,
join order was constrained using SQL syntax would be under both joins
and under version dependent kludges / performance tuning and vice versa.

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 23 Jul 2004 01:22:49 +0200

> What do you all think?

Please discuss these matters on the pgsql-docs list.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---

From: elein <[email-masked]>
Date: Thu, 22 Jul 2004 16:57:13 -0700

I think you are reviving the inheritance wars.
Please do not cut out or dumb down anything that
accurately documents our features.

I think the section should remain, describing
exactly how they work and making it clear exactly
what parts inherited and what is not inherited.
That is where the most confustion lies.

I have a documented use case where the distributed
nature of the indexes increases performance 
significantly in certain types of queries. But(!)
I have not re-tested against a recent release
so take that with a grain of salt.

I also have the documentation of how table inheritance
worked in Illustra and a bit on how it worked with
Informix IUS.  And can explain some of the thoughts
behind it and the religious wars (offline!).

However, inheritance should not take up a lot of energy that
could be better spent adding sections to JOINs, etc.

I like inhertitance, but believe that the usefulness
of our implementation is limited and so the documentation
should focus on other areas. 

elein

On Thu, Jul 22, 2004 at 03:21:04PM -0700, David Fetter wrote:
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faqs/FAQ.html

---

From: Joe Conway <[email-masked]>
Date: Thu, 22 Jul 2004 18:07:47 -0700

> should focus on other areas. 

+1

Joe

---

From: Robert Treat <[email-masked]>
Date: Thu, 22 Jul 2004 22:40:45 -0400

> > should focus on other areas.

+1/2 (Since I don't like inheritence)

IMHO we ought to try to keep the _tutorial_ free of things that are generally 
considered against relational design.  If we must keep them, move them into 
thier own section and lable them accordingly. 

Robert Treat
--- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---

From: Tom Lane <[email-masked]>
Date: Thu, 22 Jul 2004 23:14:27 -0400

> considered against relational design.

Where is it written that inheritance is against relational design?

			regards, tom lane

---

From: elein <[email-masked]>
Date: Thu, 22 Jul 2004 21:31:37 -0700

Postgresql is not simply a relational database. It is an
OBJECT relational database.  It was designed to be so from
the start.  To pretend it was designed otherwise is to
deny its design and heritage and the original intent of
the the project.  c.f. the postgres papers, stonebraker, et.al.

And like tom said, "who said inheritance is not relational."
It need not break codds rules.

--elein

On Thu, Jul 22, 2004 at 10:40:45PM -0400, Robert Treat wrote:
> TIP 4: Don't 'kill -9' the postmaster

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 23 Jul 2004 09:03:30 +0200

Tom Lane wrote:
> > IMHO we ought to try to keep the _tutorial_ free of things that are
> > generally considered against relational design.
>

I would venture that it is nowhere written that it is part of relational 
design.  It is, however, unambiguously part of object-relational 
design, if that's what we're aiming for.

---

From: David Fetter <[email-masked]>
Date: Fri, 23 Jul 2004 11:51:46 -0700

On Fri, Jul 23, 2004 at 09:03:30AM +0200, Peter Eisentraut wrote:
> > > IMHO we ought to try to keep the _tutorial_ free of things that
> > > are generally considered against relational design.
> >
> I would venture that it is nowhere written that it is part of
> relational design.  It is, however, unambiguously part of
> object-relational design, if that's what we're aiming for.

I see I have put my foot in it again.  Please bear with me here.
Object-relational in general is not broken and is being worked on.
Custom data-types, custom aggregates, etc., etc. are working just
great, and lots of people use them.

What *is* broken is table inheritance, and the docs need to reflect
this.

If the parent table has a foreign key to another table foo, CASCADEing
DELETEs on foo leave ghost entries in the tables with inheritance.
Please find enclosed a repro, which demonstrates the problem on CVS
tip and 7.4.3.

Just an FYI, I first discovered this problem in a payment system.

Cheers,
D

Remember to vote!

---

From: Tom Lane <[email-masked]>
Date: Fri, 23 Jul 2004 15:31:47 -0400

> What *is* broken is table inheritance, and the docs need to reflect

The combination of inheritance with certain other features is broken,
yes, and the docs do reflect that (see the bottom of 
http://www.postgresql.org/docs/7.4/static/ddl-inherit.html
for example).

I will grant you that this page is a near duplicate of the tutorial's
discussion of inheritance, which is surely bad --- either they should
be exact duplicates, or one or the other needs rewriting.  But I'm not
really going to hold still for the docs on inheritance being rewritten
by someone who considers the entire concept broken.  Maybe we can get
elein to do it ;-)

			regards, tom lane

---

From: David Fetter <[email-masked]>
Date: Fri, 23 Jul 2004 12:34:13 -0700

On Fri, Jul 23, 2004 at 03:31:47PM -0400, Tom Lane wrote:
> I will grant you that this page is a near duplicate of the
> tutorial's discussion of inheritance, which is surely bad --- either
> they should be exact duplicates, or one or the other needs
> rewriting.  But I'm not really going to hold still for the docs on
> inheritance being rewritten by someone who considers the entire
> concept broken.  Maybe we can get elein to do it ;-)

I don't consider the concept broken.  The implementation is, in fact,
broken, and putting that broken piece in the tutorial is, imnsho, a
bad mistake.

Cheers,
D

Remember to vote!

---

From: elein <[email-masked]>
Date: Fri, 23 Jul 2004 13:25:56 -0700

Perhaps after OSCON I can work with fetter on getting
the documentation clarified.  OK?

--elein

---

From: David Fetter <[email-masked]>
Date: Fri, 23 Jul 2004 13:28:22 -0700

On Fri, Jul 23, 2004 at 01:25:56PM -0700, elein wrote:
> Perhaps after OSCON I can work with fetter on getting the
> documentation clarified.  OK?

Sounds like fun.  There are all kinds of object-relational concepts
other than this broken piece.  Which ones are good to highlight in
that tutorial?

Cheers,
D

Remember to vote!

---

From: Tom Lane <[email-masked]>
Date: Fri, 23 Jul 2004 16:30:40 -0400

> broken, and putting that broken piece in the tutorial is, imnsho, a

If we're going to remove from the tutorial every feature for which any
aspect is deemed by someone to be broken, the tutorial is liable to
become quite short.

			regards, tom lane

---

From: David Fetter <[email-masked]>
Date: Fri, 23 Jul 2004 13:40:36 -0700

On Fri, Jul 23, 2004 at 04:30:40PM -0400, Tom Lane wrote:
> > I don't consider the concept broken.  The implementation is, in
> > fact, broken, and putting that broken piece in the tutorial is,
> > imnsho, a bad mistake.
> 
> If we're going to remove from the tutorial every feature for which
> any aspect is deemed by someone to be broken, the tutorial is liable
> to become quite short.

Are there other pieces that are broken?  As far as I know, the only
documented feature in PostgreSQL that is is table inheritance.

Anyhow, there are lots of ways to highlight the object-relational
features that PostgreSQL provides.  Table inheritance just isn't a
good one.

Cheers,
D

Remember to vote!

---

From: Tom Lane <[email-masked]>
Date: Fri, 23 Jul 2004 16:58:55 -0400

> Are there other pieces that are broken?

Between the locale behavior and the trailing-spaces behavior, one could
make the case that the entire set of textual datatypes are broken.
Other examples will occur to your thought if you follow pgsql-bugs.

My point here is that one man's unusably broken feature may be another
man's quite useful feature.  Postgres is a work in progress, and
probably always will be.  I don't object to pointing out shortcomings,
but removing all mention of a feature because it has some shortcomings
seems not the best way.

			regards, tom lane

---

From: David Fetter <[email-masked]>
Date: Fri, 23 Jul 2004 14:15:05 -0700

On Fri, Jul 23, 2004 at 04:58:55PM -0400, Tom Lane wrote:
> >> If we're going to remove from the tutorial every feature for
> >> which any aspect is deemed by someone to be broken, the tutorial
> >> is liable to become quite short.
> 
> Between the locale behavior and the trailing-spaces behavior, one
> could make the case that the entire set of textual datatypes are
> broken.  Other examples will occur to your thought if you follow
> pgsql-bugs.
> 
> My point here is that one man's unusably broken feature may be
> another man's quite useful feature.  Postgres is a work in progress,
> and probably always will be.  I don't object to pointing out
> shortcomings, but removing all mention of a feature because it has
> some shortcomings seems not the best way.

Fair enough.  How about adding an explanation of the limits of table
inheritance illustrated by that example (or other suitable one)?

Cheers,
D

Remember to vote!

---

From: Chris Browne <[email-masked]>
Date: Fri, 23 Jul 2004 18:21:17 -0400

> but removing all mention of a feature because it has some shortcomings

Ah, but suggesting that people devote time to adding documentation for
less controversial features, so that we actually _do_ see some more
documentation, seems a good thing :-).
-- 
output = reverse("moc.enworbbc" "@" "enworbbc")
http://cbbrowne.com/info/multiplexor.html
Why isn't phonetic spelled the way it sounds?