public inbox for [email protected]help / color / mirror / Atom feed
Tutorial 19+ messages / 8 participants [nested] [flat]
* Tutorial @ 2004-07-22 22:21 David Fetter <[email protected]> 0 siblings, 3 replies; 19+ messages in thread From: David Fetter @ 2004-07-22 22:21 UTC (permalink / raw) To: PG Hackers <[email protected]> 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 protected] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Tutorial @ 2004-07-22 23:12 Scott Marlowe <[email protected]> parent: David Fetter <[email protected]> 2 siblings, 0 replies; 19+ messages in thread From: Scott Marlowe @ 2004-07-22 23:12 UTC (permalink / raw) To: David Fetter <[email protected]>; +Cc: PG Hackers <[email protected]> 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. ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Tutorial @ 2004-07-22 23:22 Peter Eisentraut <[email protected]> parent: David Fetter <[email protected]> 2 siblings, 0 replies; 19+ messages in thread From: Peter Eisentraut @ 2004-07-22 23:22 UTC (permalink / raw) To: David Fetter <[email protected]>; PG Hackers <[email protected]> David Fetter wrote: > What do you all think? Please discuss these matters on the pgsql-docs list. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Tutorial @ 2004-07-22 23:57 elein <[email protected]> parent: David Fetter <[email protected]> 2 siblings, 1 reply; 19+ messages in thread From: elein @ 2004-07-22 23:57 UTC (permalink / raw) To: David Fetter <[email protected]>; +Cc: PG Hackers <[email protected]> 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 [email protected] 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 ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: Tutorial @ 2004-07-23 01:07 Joe Conway <[email protected]> parent: elein <[email protected]> 0 siblings, 1 reply; 19+ messages in thread From: Joe Conway @ 2004-07-23 01:07 UTC (permalink / raw) To: elein <[email protected]>; +Cc: David Fetter <[email protected]>; PG Hackers <[email protected]> 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 ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 02:40 Robert Treat <[email protected]> parent: Joe Conway <[email protected]> 0 siblings, 2 replies; 19+ messages in thread From: Robert Treat @ 2004-07-23 02:40 UTC (permalink / raw) To: Joe Conway <[email protected]>; elein <[email protected]>; +Cc: David Fetter <[email protected]>; pgsql-docs On Thursday 22 July 2004 21:07, Joe Conway wrote: > 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 > +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 ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 03:14 Tom Lane <[email protected]> parent: Robert Treat <[email protected]> 1 sibling, 1 reply; 19+ messages in thread From: Tom Lane @ 2004-07-23 03:14 UTC (permalink / raw) To: Robert Treat <[email protected]>; +Cc: Joe Conway <[email protected]>; elein <[email protected]>; David Fetter <[email protected]>; pgsql-docs Robert Treat <[email protected]> writes: > +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. Where is it written that inheritance is against relational design? regards, tom lane ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 04:31 elein <[email protected]> parent: Robert Treat <[email protected]> 1 sibling, 0 replies; 19+ messages in thread From: elein @ 2004-07-23 04:31 UTC (permalink / raw) To: Robert Treat <[email protected]>; +Cc: Joe Conway <[email protected]>; elein <[email protected]>; David Fetter <[email protected]>; pgsql-docs 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: > On Thursday 22 July 2004 21:07, Joe Conway wrote: > > 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 > > > > +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 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 07:03 Peter Eisentraut <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 19+ messages in thread From: Peter Eisentraut @ 2004-07-23 07:03 UTC (permalink / raw) To: Tom Lane <[email protected]>; Robert Treat <[email protected]>; +Cc: Joe Conway <[email protected]>; elein <[email protected]>; David Fetter <[email protected]>; pgsql-docs Tom Lane wrote: > Robert Treat <[email protected]> writes: > > +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. > > Where is it written that inheritance is 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. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 18:51 David Fetter <[email protected]> parent: Peter Eisentraut <[email protected]> 0 siblings, 1 reply; 19+ messages in thread From: David Fetter @ 2004-07-23 18:51 UTC (permalink / raw) To: Peter Eisentraut <[email protected]>; +Cc: Tom Lane <[email protected]>; Robert Treat <[email protected]>; Joe Conway <[email protected]>; elein <[email protected]>; pgsql-docs On Fri, Jul 23, 2004 at 09:03:30AM +0200, Peter Eisentraut wrote: > Tom Lane wrote: > > Robert Treat <[email protected]> writes: > > > +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. > > > > Where is it written that inheritance is 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 -- David Fetter [email protected] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! BEGIN; CREATE TABLE foo ( foo_id SERIAL PRIMARY KEY ); CREATE TABLE parent ( parent_id SERIAL PRIMARY KEY , foo_id INTEGER NOT NULL REFERENCES foo(foo_id) ON DELETE CASCADE , parent_1_text TEXT NOT NULL ); CREATE TABLE child_1 ( child_1_text TEXT NOT NULL ) INHERITS(parent); CREATE TABLE child_2 ( child_2_text TEXT NOT NULL ) INHERITS(parent); INSERT INTO foo VALUES(DEFAULT); INSERT INTO child_1 (foo_id, parent_1_text, child_1_text) VALUES (currval('public.foo_foo_id_seq'), 'parent text 1', 'child_1 text 1'); INSERT INTO foo VALUES(DEFAULT); INSERT INTO child_1 (foo_id, parent_1_text, child_1_text) VALUES (currval('public.foo_foo_id_seq'), 'parent text 2', 'child_1 text 2'); INSERT INTO foo VALUES(DEFAULT); INSERT INTO child_2 (foo_id, parent_1_text, child_2_text) VALUES (currval('foo_foo_id_seq'), 'parent text 3', 'child_2 text 1'); DELETE FROM foo WHERE foo_id = 1; SELECT * FROM parent; SELECT * FROM child_1; ROLLBACK; Attachments: [text/plain] wtf.sql (950B, 2-wtf.sql) download | inline: BEGIN; CREATE TABLE foo ( foo_id SERIAL PRIMARY KEY ); CREATE TABLE parent ( parent_id SERIAL PRIMARY KEY , foo_id INTEGER NOT NULL REFERENCES foo(foo_id) ON DELETE CASCADE , parent_1_text TEXT NOT NULL ); CREATE TABLE child_1 ( child_1_text TEXT NOT NULL ) INHERITS(parent); CREATE TABLE child_2 ( child_2_text TEXT NOT NULL ) INHERITS(parent); INSERT INTO foo VALUES(DEFAULT); INSERT INTO child_1 (foo_id, parent_1_text, child_1_text) VALUES (currval('public.foo_foo_id_seq'), 'parent text 1', 'child_1 text 1'); INSERT INTO foo VALUES(DEFAULT); INSERT INTO child_1 (foo_id, parent_1_text, child_1_text) VALUES (currval('public.foo_foo_id_seq'), 'parent text 2', 'child_1 text 2'); INSERT INTO foo VALUES(DEFAULT); INSERT INTO child_2 (foo_id, parent_1_text, child_2_text) VALUES (currval('foo_foo_id_seq'), 'parent text 3', 'child_2 text 1'); DELETE FROM foo WHERE foo_id = 1; SELECT * FROM parent; SELECT * FROM child_1; ROLLBACK; ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 19:31 Tom Lane <[email protected]> parent: David Fetter <[email protected]> 0 siblings, 1 reply; 19+ messages in thread From: Tom Lane @ 2004-07-23 19:31 UTC (permalink / raw) To: David Fetter <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Robert Treat <[email protected]>; Joe Conway <[email protected]>; elein <[email protected]>; pgsql-docs David Fetter <[email protected]> writes: > What *is* broken is table inheritance, and the docs need to reflect > this. 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 ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 19:34 David Fetter <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 2 replies; 19+ messages in thread From: David Fetter @ 2004-07-23 19:34 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Robert Treat <[email protected]>; Joe Conway <[email protected]>; elein <[email protected]>; pgsql-docs On Fri, Jul 23, 2004 at 03:31:47PM -0400, Tom Lane wrote: > David Fetter <[email protected]> writes: > > What *is* broken is table inheritance, and the docs need to reflect > > this. > > 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 ;-) 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 -- David Fetter [email protected] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 20:25 elein <[email protected]> parent: David Fetter <[email protected]> 1 sibling, 1 reply; 19+ messages in thread From: elein @ 2004-07-23 20:25 UTC (permalink / raw) To: David Fetter <[email protected]>; +Cc: Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Robert Treat <[email protected]>; Joe Conway <[email protected]>; elein <[email protected]>; pgsql-docs Perhaps after OSCON I can work with fetter on getting the documentation clarified. OK? --elein On Fri, Jul 23, 2004 at 12:34:13PM -0700, David Fetter wrote: > On Fri, Jul 23, 2004 at 03:31:47PM -0400, Tom Lane wrote: > > David Fetter <[email protected]> writes: > > > What *is* broken is table inheritance, and the docs need to reflect > > > this. > > > > 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 ;-) > > 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 > -- > David Fetter [email protected] http://fetter.org/ > phone: +1 510 893 6100 mobile: +1 415 235 3778 > > Remember to vote! > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 20:28 David Fetter <[email protected]> parent: elein <[email protected]> 0 siblings, 0 replies; 19+ messages in thread From: David Fetter @ 2004-07-23 20:28 UTC (permalink / raw) To: Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Robert Treat <[email protected]>; Joe Conway <[email protected]>; pgsql-docs 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 -- David Fetter [email protected] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 20:30 Tom Lane <[email protected]> parent: David Fetter <[email protected]> 1 sibling, 1 reply; 19+ messages in thread From: Tom Lane @ 2004-07-23 20:30 UTC (permalink / raw) To: David Fetter <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Robert Treat <[email protected]>; Joe Conway <[email protected]>; elein <[email protected]>; pgsql-docs David Fetter <[email protected]> writes: > 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. regards, tom lane ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 20:40 David Fetter <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 19+ messages in thread From: David Fetter @ 2004-07-23 20:40 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Robert Treat <[email protected]>; Joe Conway <[email protected]>; elein <[email protected]>; pgsql-docs On Fri, Jul 23, 2004 at 04:30:40PM -0400, Tom Lane wrote: > David Fetter <[email protected]> writes: > > 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 -- David Fetter [email protected] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 20:58 Tom Lane <[email protected]> parent: David Fetter <[email protected]> 0 siblings, 2 replies; 19+ messages in thread From: Tom Lane @ 2004-07-23 20:58 UTC (permalink / raw) To: David Fetter <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Robert Treat <[email protected]>; Joe Conway <[email protected]>; elein <[email protected]>; pgsql-docs David Fetter <[email protected]> writes: > On Fri, Jul 23, 2004 at 04:30:40PM -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. > 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 ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 21:15 David Fetter <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 0 replies; 19+ messages in thread From: David Fetter @ 2004-07-23 21:15 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Robert Treat <[email protected]>; Joe Conway <[email protected]>; elein <[email protected]>; pgsql-docs On Fri, Jul 23, 2004 at 04:58:55PM -0400, Tom Lane wrote: > David Fetter <[email protected]> writes: > > On Fri, Jul 23, 2004 at 04:30:40PM -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. > > > 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. Fair enough. How about adding an explanation of the limits of table inheritance illustrated by that example (or other suitable one)? Cheers, D -- David Fetter [email protected] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ^ permalink raw reply [nested|flat] 19+ messages in thread
* Re: [HACKERS] Tutorial @ 2004-07-23 22:21 Chris Browne <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 0 replies; 19+ messages in thread From: Chris Browne @ 2004-07-23 22:21 UTC (permalink / raw) To: pgsql-docs [email protected] (Tom Lane) writes: > David Fetter <[email protected]> writes: >> On Fri, Jul 23, 2004 at 04:30:40PM -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. > >> 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. 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? ^ permalink raw reply [nested|flat] 19+ messages in thread
end of thread, other threads:[~2004-07-23 22:21 UTC | newest] Thread overview: 19+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2004-07-22 22:21 Tutorial David Fetter <[email protected]> 2004-07-22 23:12 ` Scott Marlowe <[email protected]> 2004-07-22 23:22 ` Peter Eisentraut <[email protected]> 2004-07-22 23:57 ` elein <[email protected]> 2004-07-23 01:07 ` Joe Conway <[email protected]> 2004-07-23 02:40 ` Robert Treat <[email protected]> 2004-07-23 03:14 ` Tom Lane <[email protected]> 2004-07-23 07:03 ` Peter Eisentraut <[email protected]> 2004-07-23 18:51 ` David Fetter <[email protected]> 2004-07-23 19:31 ` Tom Lane <[email protected]> 2004-07-23 19:34 ` David Fetter <[email protected]> 2004-07-23 20:25 ` elein <[email protected]> 2004-07-23 20:28 ` David Fetter <[email protected]> 2004-07-23 20:30 ` Tom Lane <[email protected]> 2004-07-23 20:40 ` David Fetter <[email protected]> 2004-07-23 20:58 ` Tom Lane <[email protected]> 2004-07-23 21:15 ` David Fetter <[email protected]> 2004-07-23 22:21 ` Chris Browne <[email protected]> 2004-07-23 04:31 ` elein <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox