Re: Add a "Known Issues" section

Поиск
Список
Период
Сортировка
От Qingqing Zhou
Тема Re: Add a "Known Issues" section
Дата
Msg-id Pine.LNX.4.58.0601011701230.15127@eon.cs
обсуждение исходный текст
Ответ на Re: Add a "Known Issues" section  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Add a "Known Issues" section
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Why don't we allow DNS names in pg_hba.conf?