From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Marko Kreen" <markokr(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, "Sam Mason" <sam(at)samason(dot)me(dot)uk> |
Subject: | Re: [rfc] unicode escapes for extended strings |
Date: | 2009-04-17 21:27:36 |
Message-ID: | 28853.1240003656@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> ISTM that one of the uses of this is to say "store the character
>> that corresponds to this Unicode code point in whatever the database
>> encoding is"
> I would think you're right. As long as the given character is in the
> user's character set, we should allow it. Presumably we've already
> confirmed that they have an encoding scheme which allows them to store
> everything in their character set.
This is a good way to get your patch rejected altogether. The lexer
is *not* allowed to invoke any database operations (such as
pg_conversion lookups) so it cannot perform arbitrary encoding
conversions.
If this sort of facility is what you want, the previously suggested
approach via a decode-like runtime function is a better fit.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-04-17 21:33:59 | Re: [rfc] unicode escapes for extended strings |
Previous Message | David Fetter | 2009-04-17 21:10:30 | Re: psql with "Function Type" in \df |