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, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: 8.4 open items list
Date: 2009-04-01 16:50:55
Message-ID: 603c8f070904010950w66ee9e7atf635310793aee685@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Mar 28, 2009 at 12:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 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:
>
>> CREATE DATABASE foo WITH LOCALE = bar
>> equivalent to...
>> CREATE DATABASE foo WITH COLLATE = bar, CTYPE = bar
>
>> That might be nice to have, but since it's just syntactic sugar, I
>> disagree that it's now or never.
>
> The reason I wanted it considered now is that part of the discussion
> was about whether to rename the existing options (add or remove LC_,
> I forget which).  Once 8.4 is out it'll be too late to reconsider that.

The current situation is not horribly consistent because createdb uses
--lc-foo and the SQL syntax uses FOO. I'm not sure which is better,
or whether it's worth making them consistent. As Dave Page pointed
out, other people have already started designing tools based on CVS
HEAD. At any rate, I don't think we can make LC-FOO a keyword - it
would have to be LC_FOO or something.

>> 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.
>
> +1.  And this is something it'd be better to get right now than later,
> since it's about an API that's meant to be used by add-on modules.

Hearing no objections, I guess we need a committer to pick up the
patch and consider applying. Maybe Alvaro since he did the previous
reloptions work, but I don't know if he has time.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2009-04-01 16:52:50 Re: [HACKERS] string_to_array with empty input
Previous Message Tom Lane 2009-04-01 16:02:18 Re: [HACKERS] string_to_array with empty input