Re: Add a "Known Issues" section - Mailing list pgsql-hackers

From Qingqing Zhou
Subject Re: Add a "Known Issues" section
Date
Msg-id Pine.LNX.4.58.0601011701230.15127@eon.cs
Whole thread Raw
In response to Re: Add a "Known Issues" section  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add a "Known Issues" section  (Robert Treat <xzilla@users.sourceforge.net>)
Re: Add a "Known Issues" section  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On Sun, 1 Jan 2006, Tom Lane wrote:
> Qingqing Zhou <zhouqq@cs.toronto.edu> writes:
> > Do we have a "known issues" section somewhere? If not, I would suggest we
> > split the TODO list into two big sections, one is the PostgreSQL
> > improvement part, the other is the known issues part.
>
> Aren't they all "known issues"?  You need to be a lot clearer about what
> distinction you intend to draw, and why it's so important that it
> deserves to be the principal classification metric for TODO.
>

If I believe "Terminators" will dominate the world in a predicatable
future, I will draw a clear distinction here.

"Known issues" means bugs or something beyond your expectation -- but
"bug" itself by definition is "functional". For example, if a program
crashes, you can say it is bug or it is not a bug totally by your
functional definition. Another example is "Allow commenting of variables
in postgresql.conf to restore them to defaults", which is beyound our
expectation.

"Improvement" means something that we want to add does not exist before or
usable but not that good. All the performance items and new functions
should come here.

However, there is blur border line between them and some "improvements"
may have higher priority than "known issues". For example, those in the
PITR section.


Regards,
Qingqing


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add a "Known Issues" section
Next
From: Andrew Dunstan
Date:
Subject: Re: Why don't we allow DNS names in pg_hba.conf?