> > The reason it will help with support is because newbies will go 
> > "SQL_ASCII! I don't want ascii!".
> 
> No they won't.  They will likely not even notice this message 
> in the sea of other messages they've never seen before; and 
> even if they do notice it, they will certainly not realize 
> that they don't want it.  If the message were to *say* "this 
> is probably a bad choice because it's incompatible with your 
> locale selection", then it might possibly have the effect 
> you're hoping for, but I don't see how we can find that out.

Another way would be to make -E a mandatory parameter, and remove the
default completely. That way you have to make a conscious decision.
Can't claim surprise then.


//Magnus

Mon, 21 Jun 2004 16:55:54 +0200
"Magnus Hagander" <mha@sollentuna.net>
Re: Show encoding in initdb messages 
"Magnus Hagander" <mha@sollentuna.net> writes:
>>> The reason it will help with support is because newbies will go 
>>> "SQL_ASCII! I don't want ascii!".
>> 
>> No they won't.  They will likely not even notice this message 
>> in the sea of other messages they've never seen before; and 
>> even if they do notice it, they will certainly not realize 
>> that they don't want it.

> Another way would be to make -E a mandatory parameter, and remove the
> default completely. That way you have to make a conscious decision.
> Can't claim surprise then.

I don't think surprise is the problem; I think the problem is knowing
what setting will produce the result you want.  Newbies are
fundamentally unlikely to have this knowledge :-(

What I personally wish we could do is eliminate database encoding as
a separate setting altogether, and drive it off the locale selection.
I don't know how to do that though.

			regards, tom lane

Mon, 21 Jun 2004 11:12:11 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Show encoding in initdb messages 
Tom Lane wrote:
> What I personally wish we could do is eliminate database encoding as
> a separate setting altogether, and drive it off the locale selection.
> I don't know how to do that though.

The information is available:

$ LANG=de_DE locale charmap
ISO-8859-1
$ LANG=de_DE@euro locale charmap
ISO-8859-15
$ LANG=de_DE.utf8 locale charmap
UTF-8

But the answer space is infinite:

$ LANG=C locale charmap
ANSI_X3.4-1968

I suspect Japanese users will also have a problem with this mechanism, 
but at least we could keep -E to override the automatic selection.


Mon, 21 Jun 2004 17:46:56 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: Show encoding in initdb messages
Peter Eisentraut <peter_e@gmx.net> writes:
> But the answer space is infinite:

> $ LANG=C locale charmap
> ANSI_X3.4-1968

Right, the hard part is mapping whatever weird string "locale charmap"
chooses to return into one of the encodings our code knows about.

HPUX seems to be just arbitrarily bizarre:

$ LC_ALL=en_US.iso88591 locale charmap
"iso88591.cm"
$ LC_ALL=C.utf8 locale charmap
"utf8.cm"
$

As near as I can tell, the .cm is present in all the possible results;
and why the quotes?

> I suspect Japanese users will also have a problem with this mechanism, 
> but at least we could keep -E to override the automatic selection.

Perhaps we could try to derive a setting from locale charmap, but barf
and require explicit -E if we can't recognize it?

			regards, tom lane

Mon, 21 Jun 2004 12:03:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Show encoding in initdb messages 
Tom Lane wrote:

>Peter Eisentraut <peter_e@gmx.net> writes:
>  
>
>>But the answer space is infinite:
>>    
>>
>
>  
>
>>$ LANG=C locale charmap
>>ANSI_X3.4-1968
>>    
>>
>
>Right, the hard part is mapping whatever weird string "locale charmap"
>chooses to return into one of the encodings our code knows about.
>
>HPUX seems to be just arbitrarily bizarre:
>
>$ LC_ALL=en_US.iso88591 locale charmap
>"iso88591.cm"
>$ LC_ALL=C.utf8 locale charmap
>"utf8.cm"
>$
>
>As near as I can tell, the .cm is present in all the possible results;
>and why the quotes?
>  
>


>  
>
>>I suspect Japanese users will also have a problem with this mechanism, 
>>but at least we could keep -E to override the automatic selection.
>>    
>>
>
>Perhaps we could try to derive a setting from locale charmap, but barf
>and require explicit -E if we can't recognize it?
>
>  
>

Sounds like an excellent plan, at least for platforms that have such a 
command. Windows does not appear to :-(. Are there other *nixes that 
also lack it, or that also produce bizarre results like PH-UX?

cheers

andrew

Mon, 21 Jun 2004 12:22:19 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: Show encoding in initdb messages
Am Montag, 21. Juni 2004 18:03 schrieb Tom Lane:
> Perhaps we could try to derive a setting from locale charmap, but barf
> and require explicit -E if we can't recognize it?

Considering that we now have a functioning lower/upper, we should try to get 
this fixed so users can enjoy the fixed situation without further surprising 
mismatches.

The SUS appears to specify that the OS encoding names are 
implementation-defined.  We can provide a big mapping table, but I would like 
to ask other people to show what kind of encoding names their OS has.  Please 
send me the output of locale -m (or if you don't have a locale command, tell 
me).

Fri, 2 Jul 2004 16:56:56 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: [PATCHES] Show encoding in initdb messages

Is this a TODO?

---------------------------------------------------------------------------

Andrew Dunstan wrote:
> Tom Lane wrote:
> 
> >Peter Eisentraut <peter_e@gmx.net> writes:
> >  
> >
> >>But the answer space is infinite:
> >>    
> >>
> >
> >  
> >
> >>$ LANG=C locale charmap
> >>ANSI_X3.4-1968
> >>    
> >>
> >
> >Right, the hard part is mapping whatever weird string "locale charmap"
> >chooses to return into one of the encodings our code knows about.
> >
> >HPUX seems to be just arbitrarily bizarre:
> >
> >$ LC_ALL=en_US.iso88591 locale charmap
> >"iso88591.cm"
> >$ LC_ALL=C.utf8 locale charmap
> >"utf8.cm"
> >$
> >
> >As near as I can tell, the .cm is present in all the possible results;
> >and why the quotes?
> >  
> >
> 
> 
> >  
> >
> >>I suspect Japanese users will also have a problem with this mechanism, 
> >>but at least we could keep -E to override the automatic selection.
> >>    
> >>
> >
> >Perhaps we could try to derive a setting from locale charmap, but barf
> >and require explicit -E if we can't recognize it?
> >
> >  
> >
> 
> Sounds like an excellent plan, at least for platforms that have such a 
> command. Windows does not appear to :-(. Are there other *nixes that 
> also lack it, or that also produce bizarre results like PH-UX?
> 
> cheers
> 
> andrew
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faqs/FAQ.html
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 5 Jul 2004 09:29:33 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Show encoding in initdb messages