Re: Add a "Known Issues" section

From: Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add a "Known Issues" section
Date: 2006-01-01 22:30:32
Message-ID: Pine.LNX.4.58.0601011701230.15127@eon.cs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 1 Jan 2006, Tom Lane wrote:
> Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2006-01-01 23:37:22 Re: Why don't we allow DNS names in pg_hba.conf?
Previous Message Tom Lane 2006-01-01 21:52:51 Re: Add a "Known Issues" section