Thread: Tutorial
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!
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.
David Fetter wrote: > What do you all think? Please discuss these matters on the pgsql-docs list. -- Peter Eisentraut http://developer.postgresql.org/~petere/
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
elein wrote: > I like inhertitance, but believe that the usefulness > of our implementation is limited and so the documentation > should focus on other areas. +1 Joe