Bruce Momjian wrote:
Tom Lane wrote:
Alvaro Herrera writes:
Heikki Linnakangas wrote:
Hmm, I remember I pondered for a long time if it should be COLLATE and
CTYPE or LC_COLLATE and LC_CTYPE. I think the rationale in the end was
that a) COLLATE/CTYPE looks nicer and b) if we add support for
Tom Lane wrote:
> Alvaro Herrera writes:
> > Heikki Linnakangas wrote:
> >> Hmm, I remember I pondered for a long time if it should be COLLATE and
> >> CTYPE or LC_COLLATE and LC_CTYPE. I think the rationale in the end was
> >> that a) COLLATE/CTYPE looks nicer and b) if we add support for ICU
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> >> You missed updating the sgml docs, and personally I'd be inclined to
> >> list -l before the individual --lc switches; otherwise it looks fine.
> > Thanks, committed that way. I noticed that --lc-ctype and --lc-collate
> > were fo
Alvaro Herrera writes:
> Heikki Linnakangas wrote:
>> Hmm, I remember I pondered for a long time if it should be COLLATE and
>> CTYPE or LC_COLLATE and LC_CTYPE. I think the rationale in the end was
>> that a) COLLATE/CTYPE looks nicer and b) if we add support for ICU or
>> some other collat
Heikki Linnakangas wrote:
> Peter Eisentraut wrote:
>> I notice in the documentation that the createdb --lc-ctype sets the
>> lc_ctype setting for the database, but the corresponding parameter for
>> CREATE DATABASE is CTYPE, but the global GUC setting is lc_ctype.
>> Should that be more cons
Peter Eisentraut wrote:
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
Which raises yet another question, why CTYPE and COLLATE have to be
hardcoded settings and catalog columns instead of being stored in
datconfig as database-startup-only settings?
Because changing CTYPE or COLLATE in an
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
Which raises yet another question, why CTYPE and COLLATE have to be
hardcoded settings and catalog columns instead of being stored in
datconfig as database-startup-only settings?
Because changing CTYPE or COLLATE in an existing database would
Peter Eisentraut wrote:
Which raises yet another question, why CTYPE and COLLATE have to be
hardcoded settings and catalog columns instead of being stored in
datconfig as database-startup-only settings?
Because changing CTYPE or COLLATE in an existing database would render
indexes broken.
P
Bruce Momjian wrote:
You missed updating the sgml docs, and personally I'd be inclined to
list -l before the individual --lc switches; otherwise it looks fine.
Thanks, committed that way. I noticed that --lc-ctype and --lc-collate
were forgotten in SGML docs, so I added them too.
Should we hav
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Heikki Linnakangas wrote:
> >> Alvaro Herrera wrote:
> >>> Tom Lane wrote:
> Alvaro Herrera writes:
> > Alvaro Herrera wrote:
> >> I like Teodor's proposal; I'll see about implementing that.
> > Attached.
> You missed updatin
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera writes:
Alvaro Herrera wrote:
I like Teodor's proposal; I'll see about implementing that.
Attached.
You missed updating the sgml docs, and personally I'd be inclined to
list -l before the i
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> > Tom Lane wrote:
> >> Alvaro Herrera writes:
> >>> Alvaro Herrera wrote:
> I like Teodor's proposal; I'll see about implementing that.
> >>> Attached.
> >> You missed updating the sgml docs, and personally I'd be inclined to
> >> list -l be
Alvaro Herrera wrote:
> I like Teodor's proposal; I'll see about implementing that.
Attached.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Index: src/bin/scripts/createdb.c
===
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> I like Teodor's proposal; I'll see about implementing that.
> Attached.
You missed updating the sgml docs, and personally I'd be inclined to
list -l before the individual --lc switches; otherwise it looks fine.
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Seems to me there's one there already.
>
> > You're thinking of initdb maybe? I'm talking about createdb.
>
> Oh, okay. But how often is someone going to be changing locales during
> createdb? I think the mos
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Alvaro Herrera wrote:
I like Teodor's proposal; I'll see about implementing that.
Attached.
You missed updating the sgml docs, and personally I'd be inclined to
list -l before the individual --lc switches; other
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> I like Teodor's proposal; I'll see about implementing that.
>
> > Attached.
>
> You missed updating the sgml docs, and personally I'd be inclined to
> list -l before the individual --lc switches; otherwise
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Seems to me there's one there already.
> You're thinking of initdb maybe? I'm talking about createdb.
Oh, okay. But how often is someone going to be changing locales during
createdb? I think the most common case might well be like
Tom Lane wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> It seems awkward; why can't we just have a
> >> single --locale switch that selects both settings at once?
>
> > Sometimes it's needed to use C-collate with non-C-ctype. But for most
> > users it's enough j
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> It seems awkward; why can't we just have a
>> single --locale switch that selects both settings at once?
> Sometimes it's needed to use C-collate with non-C-ctype. But for most
> users it's enough just a locale switch. What abou
Alvaro Herrera wrote:
Hi,
I just noticed that the interface for choosing a different locale at db
creation time is
createdb --lc-collate=X --lc-ctype=X. Is there a reason for having
these two separate switches? It seems awkward; why can't we just have a
single --locale switch that selects both
21 matches
Mail list logo
