Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
FWIW I tried this program here, and I get
C ... ANSI_X3.4-1968 - NO MATCH
POSIX ... ANSI_X3.4-1968 - NO MATCH
Note the funny name. Trying initdb with LC_ALL=C correctly uses
SQL_ASCII (I saw
Tom Lane wrote:
I tried this program on Mac OS X 10.4.10 (the current release) and found
out that what that OS mostly returns is the encoding portion of the
locale name, for instance
FWIW I tried this program here, and I get
C ... ANSI_X3.4-1968 - NO MATCH
POSIX
Alvaro Herrera [EMAIL PROTECTED] writes:
FWIW I tried this program here, and I get
C ... ANSI_X3.4-1968 - NO MATCH
POSIX ... ANSI_X3.4-1968 - NO MATCH
Note the funny name. Trying initdb with LC_ALL=C correctly uses
SQL_ASCII (I saw the special case
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Another possibility is to treat the case as a WARNING if you're
superuser and an ERROR if you're not. This would satisfy people
who are uncomfortable with the idea that CREATEDB privilege comes
with a built-in denial-of-service
Tom Lane [EMAIL PROTECTED] writes:
Another possibility is to treat the case as a WARNING if you're
superuser and an ERROR if you're not. This would satisfy people
who are uncomfortable with the idea that CREATEDB privilege comes
with a built-in denial-of-service attack, while still leaving a
I was reminded again just now of the bad consequences of selecting a
database encoding that is not compatible with your LC_CTYPE setting:
http://archives.postgresql.org/pgsql-bugs/2007-09/msg00158.php
Aside from that one, which is perilously close to being a denial of
service attack, there are
Andrew Dunstan [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Another possibility is to treat the case as a WARNING if you're
superuser and an ERROR if you're not. This would satisfy people
who are uncomfortable with the idea that CREATEDB privilege comes
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Another possibility is to treat the case as a WARNING if you're
superuser and an ERROR if you're not. This would satisfy people
who are uncomfortable with the idea that CREATEDB
Zdenek Kotala [EMAIL PROTECTED] writes:
On Solaris I got following problematic locales:
C ... 646- NO MATCH
POSIX ... 646- NO MATCH
cs ... 646- NO MATCH
da ... 646- NO MATCH
et
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
On Solaris I got following problematic locales:
C ... 646- NO MATCH
POSIX ... 646- NO MATCH
cs ... 646- NO MATCH
da ... 646
Zdenek Kotala [EMAIL PROTECTED] writes:
On Solaris I got following problematic locales: [...]
I tried this program on Mac OS X 10.4.10 (the current release) and found
out that what that OS mostly returns is the encoding portion of the
locale name, for instance
sv_SE.ISO8859-15...
Zdenek Kotala [EMAIL PROTECTED] writes:
The another question is what do when we know that this codeset/encoding
is not supported by postgres.
Ah, I finally grasped what you were on about here. As CVS HEAD stands,
if you run initdb in an unrecognized locale, you get something like
$
12 matches
Mail list logo
