From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Jan Lentfer <jan(dot)lentfer(at)web(dot)de>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Encoding problems with "COMMENT ON DATABASE .." causing pg_restore (and pg_upgrade) to fail |
Date: | 2016-02-16 20:24:24 |
Message-ID: | 12470.1455654264@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Tue, Feb 16, 2016 at 01:36:24PM -0600, Jim Nasby wrote:
>> Could we force the global catalogs to always be accessed via UTF8,
>> at least for modification? I suspect that would mean changing
>> encodings on the fly in the appropriate command functions (such as
>> what's listed in src/include/commands/user.h).
> I don't remember us favoring UTF8 in this way in the past.
Yeah. I'm pretty sure the Far Eastern contingent has specifically lobbied
against giving UTF8 such a preference. Also, if a name in the shared
catalog is UTF8, what do you do when it cannot be converted to the local
database encoding? I don't think pretending the entry isn't there will do.
Perhaps a reasonable thing for now is to document that it's a bad idea
to put non-ASCII characters in names or comments of shared objects
(databases, roles, tablespaces) unless all databases of the cluster share
the same encoding. I don't know if it would be useful/practical to try
to mechanically enforce such a rule, but we could at least warn people
about the issue.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2016-02-17 00:01:47 | Re: Documentation Error - Update YUM repository page to reflect 9.5 support |
Previous Message | Jim Nasby | 2016-02-16 20:12:41 | Re: Encoding problems with "COMMENT ON DATABASE .." causing pg_restore (and pg_upgrade) to fail |