Skip site navigation (1) Skip section navigation (2)

Re: 8.4 open items list

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.4 open items list
Date: 2009-03-28 16:06:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> and the first two items from the "questions" category, which
>> don't seem important enough to worry about at this stage of the game.
> Both of those things are related to 8.4 feature changes, so we should
> either do them now or decide we won't do them.

Well, "Should we have a LOCALE option in CREATE DATABASE?" has to do
with making:

equivalent to...

That might be nice to have, but since it's just syntactic sugar, I
disagree that it's now or never.

The second item, "Should we reject toast.fillfactor in reloptions?",
comes with a patch.  I think I agree with ITAGAKI Takahiro that it
would be better to have reloptions specify a set of RELOPT_KINDs to
which they pertain rather than a single one.  There are likely to be
other types of reloptions that could apply to more than one category
of objects, and duplicating the definitions is not a desirable coping
strategy.  So I guess I'm in favor of applying this patch if others
are satisfied with the quality of the code (which I have looked at,
but only briefly).  Given the fact that anyone who understands both
toast and fillfactor should know that they don't make sense together
(and we can also document this), I don't think too many people will
get bitten if we ignored this issue for 8.4 and then applied the patch
to 8.5, but since the code is already written, there may be no reason
to take the risk.


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-03-28 16:25:16
Subject: Re: 8.4 open items list
Previous:From: Andrew GierthDate: 2009-03-28 15:45:58
Subject: Re: TODO item

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group