Re: Supporting SJIS as a database encoding

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: "'Tatsuo Ishii'" <ishii(at)sraoss(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Supporting SJIS as a database encoding
Date: 2016-09-05 14:47:15
Message-ID: 9599.1473086835@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> writes:
> Before digging into the problem, could you share your impression on
> whether PostgreSQL can support SJIS? Would it be hopeless?

I think it's pretty much hopeless. Even if we were willing to make every
bit of code that looks for '\' and other specific at-risk characters
multi-byte aware (with attendant speed penalties), we could expect that
third-party extensions would still contain vulnerable code. More, we
could expect that new bugs of the same ilk would get introduced all the
time. Many such bugs would amount to security problems. So the amount of
effort and vigilance required seems out of proportion to the benefits.

Most of the recent discussion about allowed backend encodings has run
more in the other direction, ie, "why don't we disallow everything but
UTF8 and get rid of all the infrastructure for multiple backend
encodings?". I'm not personally in favor of that, but there are very
few hackers who want to add any more overhead in this area.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2016-09-05 14:50:28 Re: Vacuum: allow usage of more than 1GB of work mem
Previous Message Simon Riggs 2016-09-05 14:34:29 Re: new autovacuum criterion for visible pages