Re: multibyte-character aware support for function "downcase_truncate_identifier()"

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Rajanikant Chirmade <rajanikant(dot)chirmade(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: multibyte-character aware support for function "downcase_truncate_identifier()"
Date: 2010-11-23 18:21:43
Message-ID: AANLkTino65ZV+Pk43PPAaKQHQ7nY1W6i9yf8KMphdoma@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 23, 2010 at 5:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The case I was worried about is dumping from one database and reloading
> into another one with a different locale.  Although I suppose there are
> enough *other* reasons why that might fail that adding changes of
> downcasing behavior might not be a big deal.

If you dump the whole database then pg_dump would create the new
database with the correct encoding and locale. If you change it then
that can already cause it to fail if the data can't be converted to
the new encoding. And as you point out there are all kinds of ways
you can cause that to fail by making the context incompatible with the
definitions you're loading.

The lesson we learned in the past is that we have to ignore the locale
for all the characters present in the standard identifiers. Beyond
that I think this is just an implementation problem which may be a
show stopper in itself but if we can do anything with mulitbyte
characters it's probably an improvement over what we do now.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2010-11-23 18:22:02 Re: SQL/MED estimated time of arrival?
Previous Message Heikki Linnakangas 2010-11-23 18:18:48 Re: SQL/MED estimated time of arrival?