Date: Thu, 22 Jul 2004 17:12:27 -0600
Message-Id: <1090537947.709.55.camel@localhost.localdomain>
From: "Scott Marlowe" <smarlowe@qwest.net>
To: "David Fetter" <david@fetter.org>
Cc: "PG Hackers" <pgsql-hackers@postgresql.org>
Subject: Re: Tutorial
In-Reply-To: <20040722222104.GU7751@fetter.org>
References: <20040722222104.GU7751@fetter.org>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Thu, 2004-07-22 at 16:21, David Fetter wrote:
> 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'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.

> 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.

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.