Date: Thu, 22 Jul 2004 16:57:13 -0700
From: elein <elein@varlena.com>
To: David Fetter <david@fetter.org>
Cc: PG Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Tutorial
Message-ID: <20040722165713.A29889@cookie.varlena.com>
Mail-Followup-To: David Fetter <david@fetter.org>,
	PG Hackers <pgsql-hackers@postgresql.org>
References: <20040722222104.GU7751@fetter.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040722222104.GU7751@fetter.org>
User-Agent: Mutt/1.3.22.1i

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:
> 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 david@fetter.org http://fetter.org/
> phone: +1 510 893 6100   mobile: +1 415 235 3778
> 
> Remember to vote!
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faqs/FAQ.html