From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-02 07:47:37 |
Message-ID: | 49D46D99.4030308@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas wrote:
> 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.
I pondered for a long time whether to call the options "COLLATE" and
"CTYPE", or "LC_COLLATE" and "LC_CTYPE". I went with COLLATE and CTYPE
in the end, one reason being that there was discussion on having ICU
support as an option in the future. Calling the option LC_COLLATE would
be misleading, since the collation would actually be implemented by ICU,
with no connection to the operating system LC_COLLATE environment
variable. If we get finer grained collations (column level etc.) it
would be nice to not call it "LC_COLLATE" everywhere, but just
"collation". In fact, perhaps the keyword should be "COLLATION" instead
of COLLATE? But what to do with CTYPE then?
I'm still not sure which is actually better, though. On the other hand,
now that LC_COLLATE does refer to the environment variable, it would be
nice to spell it "LC_COLLATE". I think I'm leaning more towards
LC_COLLATE now that I've lived with it for a while...
> As Dave Page pointed
> out, other people have already started designing tools based on CVS
> HEAD.
Now is the time to decide, before the PostgreSQL beta is out. I
understand the pain inflicted on tools, but I don't think that's a good
reason to not change it. People using a beta version of pgAdmin will
should understand that it's not final yet and there can be small
glitches like that.
> At any rate, I don't think we can make LC-FOO a keyword - it
> would have to be LC_FOO or something.
Yeah, LC_COLLATE is what the environment variable is called too.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2009-04-02 08:03:29 | Re: 8.4 open items list |
Previous Message | Jacky Leng | 2009-04-02 07:25:21 | Bug of ALTER TABLE DROP CONSTRAINT |