| 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: | Whole Thread | Raw Message | 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 |